Received: from mail-la0-f56.google.com ([209.85.215.56]:56462) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XdJqv-0001sr-CX for lojban-list-archive@lojban.org; Sun, 12 Oct 2014 07:10:39 -0700 Received: by mail-la0-f56.google.com with SMTP id pv20sf573137lab.11 for ; Sun, 12 Oct 2014 07:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type; bh=CoNn38TGMd+2+p37e64llZys1dQ2eZqVYG2nRcB50TM=; b=DQ5BQDXlRqzOOufAG2ibbavqc7k4Aj+fOc6sQzOambPB9KWFv5MMUBHq3nv75fFiqq k0GJbkrPTD5fH7iLAKGW9qFOowe1SNgoeJBtPZKUAJks61IOY0mE5dTrcpCZW+t/BW7h lNzvbgV/eOV/E2esvWajtixzRRrnOC9ZuLkaq6sL6ds34SFgRv/VTOT408NKn1N+Uf4J YCKPQpr1+ZfDhUP3JkUQa5i7jEx/+rJBLGdQF4MfkvB5P/zyzL0TSmnat/RVgyyOQv/f mSmMul1mAsWiYA0IIBNPL62fSQRVK7Tal6hfyGGG4dXJZD3ladesWpSjBygVjaqq3ZE8 cjdA== X-Received: by 10.152.28.41 with SMTP id y9mr271526lag.2.1413123021944; Sun, 12 Oct 2014 07:10:21 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.152.8.68 with SMTP id p4ls402370laa.52.gmail; Sun, 12 Oct 2014 07:10:21 -0700 (PDT) X-Received: by 10.152.29.167 with SMTP id l7mr94715lah.3.1413123021072; Sun, 12 Oct 2014 07:10:21 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [2a00:1450:4010:c03::235]) by gmr-mx.google.com with ESMTPS id rb5si399457lbb.0.2014.10.12.07.10.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 07:10:21 -0700 (PDT) Received-SPF: pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:4010:c03::235 as permitted sender) client-ip=2a00:1450:4010:c03::235; Received: by mail-la0-x235.google.com with SMTP id gq15so5380233lab.40 for ; Sun, 12 Oct 2014 07:10:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.27.40 with SMTP id q8mr2697969lag.92.1413123020968; Sun, 12 Oct 2014 07:10:20 -0700 (PDT) Received: by 10.114.61.107 with HTTP; Sun, 12 Oct 2014 07:10:20 -0700 (PDT) In-Reply-To: <20141012012427.GF23876@gonzales> References: <20141009010533.GF18854@gonzales> <20141009233031.GC1592@gonzales> <20141010234033.GG22868@gonzales> <20141011021201.GH22868@gonzales> <20141011143749.GD23876@gonzales> <20141012012427.GF23876@gonzales> Date: Sun, 12 Oct 2014 11:10:20 -0300 Message-ID: Subject: Re: [lojban] Re: tersmu 0.2 From: =?UTF-8?Q?Jorge_Llamb=C3=ADas?= To: lojban@googlegroups.com X-Original-Sender: jjllambias@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:4010:c03::235 as permitted sender) smtp.mail=jjllambias@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: lojban@googlegroups.com Precedence: list Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com List-ID: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary=089e0158c5aab056c005053a5798 X-Spam-Score: -1.9 (-) X-Spam_score: -1.9 X-Spam_score_int: -18 X-Spam_bar: - --089e0158c5aab056c005053a5798 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 11, 2014 at 10:24 PM, Martin Bays wrote: > > So I think we should aim to find a single rule which will handle all > qualifiers but {tu'a}. > > Let's think it through from scratch. > > The simplest approach, and what is assumed by tersmus in its current > form, is to have each qualifier interpreted as a unary function, and > each non-logical connective as a binary function. This arguably makes > sense for all LAhE and JOI except {tu'a} and {ju'e}, Why doesn't it make sense for "tu'a", is it because of the vague "co'e" or because of the embedding of its argument in a subordinate clause? It has a more complicated structure than most LAhE, and its precise meaning depends on context, but it is still a unary function, isn't it? "ju'e" I agree is probably not a binary function if it's supposed to be the compressed form of ".i". I would say "fa'u" is also in the same boat as "ju'e". > but is a bit > strange for {NAhE bo}, and is marginal for {la'e} and {lu'e}, since the > referent-symbol relation isn't really bijective. > "cmima" is not bijective either, so if that was a requisite you'd have to include "lu'a" and "lu'i" among the marginals. which leaves only "lu'o" and "vu'i". > So relaxing that slightly, we can have qualifiers resp non-logical > connectives interpreted as binary resp ternary relations (which in many > cases are graphs of functions, but we don't require that). There's > a reasonably obvious choice for the relation in every case (even {fa'u}, > if we're willing to clutter our universe up with a special data type to > handle it, which I think should be fine really). > Can "ko'a fa'u ko'e prami vei ro fa'u su'o ko'i" be handled with a special data type? So {LAhE ko'a} -> LAhE(x,ko'a), and we still have to decide how to > extract a term from this unary predicate. We have the usual options - we > can quantify (universally or existentially, plurally or singularly, with > various possibilities for the scope), we can take the mereological sum > of the extension (with or without a presupposition that this also > satisfies the predicate), we can take the kind, we can have the speaker > pick something(s) in the extension without further specification > (possibly with some restriction like it having to be somehow salient). > I think that's exhaustive (and so ta'o ru'e I think {lo} must be one of > these, or be ambiguous between some of them, cf bottom of this mail). > > CLL lojban takes the quantification route. Based on the examples in CLL, > it looks like the implicit quantifier is {su'o}. > > With xorlo, the natural choice is {lo}. > Yes. So this gets us (back) to {LAhE ko'a} -> {lo [LAhE] be ko'a}. > Maybe even {tu'a ko'a} can be put in that form. > "tu'a ko'a" could be "lo dumco'e be ko'a", but the problem is that "tu'a su'o ko'a" is supposed to be "lo du'u su'o ko'a co'e", which doesn't work with "dumco'e". > Then there's the question of what to do with quantifiers and logically > connected sumti. Transparency is the simplest option, since it reduces > us directly to the case we've just dealt with, but it doesn't give the > desired semantics to {tu'a}. Sorry, which case? Sticking to the model described above, the > only alternative seems to be to have the logical operators operate on > the unary predicate, yielding e.g. {LAhE re da} -> {lo poi'i re da zo'u > LAhE be da}. > I would call this one the simplest, the one that gives "lu'a ko'a .e ko'e" = "lo cmima be ko'a .e ko'e" rather than "lo cmima be ko'a ku .e lo cmima be ko'e". > But this *still* doesn't give the desired semantics to {tu'a}. > So we give up on including {tu'a}, and handle it separately. > Right, because "tu'a" was introduced precisely to kill the usual "pseudo-term as bridi operator" rules, so it is expected that those rules will fail with "tu'a". So finally, all we're left with is: > 1. defining the binary/ternary relation for each word; > 2. deciding between the two options for handling logical operators; > 3. deciding whether there should be any other exceptions. > > 1 is the business of a dictionary, not this thread. > > I hope we can agree that the default for 3 should be "no" unless > there's a pressing reason. > "tu'a", "fa'u" and "ju'e", or just "tu'a"? "fa'u" and "ju'e" are exceptions in an opposite sense than "tu'a". Whereas "tu'a" constrains the bridi-operators that it takes as arguments to act on a subordinate predicate, "fa'u" and "ju'e" are themselves bridi operators that act on a superordinate bridi. For 2: either choice seems reasonable. I'd prefer transparency just > because it's simpler - but if you think, with {tu'a} entirely ignored, > that it's important to have opaqueness, then I'm happy to accept that. > Do you? > I don't agree transparency is simpler. Also, to give an argument of the kind that And would disapprove of, I think that as a general rule sumti-6 should not be bridi operators, and since LAhE is in sumti-6, it should generate a logical term, not a pseudo-term. This argument doesn't apply to JOI, which shows up higher up in the grammar. > > Regarding {lo}: could it be the "down" operator which extracts a kind > > > from a predicate? I'm not seeing any other options, if it is "definite" > > > and if \iota is out. > > > > That kind of presupposes that among all the various operators that > > linguists/logicians/etc have defined, described, explored there has to be > > one that matches "lo". I don't know enough about the subject to give an > > opinion one way or the other. > > I intended no such presupposition. If it's something already named and > analysed, that makes things easier, but it isn't necessary. I really > honestly meant that I don't see what else {lo} could mean. In the > exhaustive-as-far-as-I-can-see list of plausible ways of extracting > a term from a unary predicate I gave above, if we rule out > quantification, require that the predicate determines the term > ("definiteness"), and require that the resulting term satisfies the > predicate, then we're left with only these two possibilities: > mereological sum of the extension with a presupposition that this > satisfies the predicate (\iota) > or > the kind corresponding to the predicate (down). > > Am I missing some possibilities? If one of these operators gives reasonable meanings to all of these sentences, I would say go for it: lo ci cukta poi mi tcidu ca lo ca masti cu cpana lo vi jubme mi nelci lo ka limna mi ca'o pinxe lo djacu lo djacu cu dunja lo ka kelvo li no lo cipni cu se farvi lo dinsauru 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. --089e0158c5aab056c005053a5798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Oct 11, 2014 at 10:24 PM, Martin Bays <mbays@sdf.org> wr= ote:

So I think we should aim to find a single rule which will handle all
qualifiers but {tu'a}.

Let's think it through from scratch.

The simplest approach, and what is assumed by tersmus in its current
form, is to have each qualifier interpreted as a unary function, and
each non-logical connective as a binary function. This arguably makes
sense for all LAhE and JOI except {tu'a} and {ju'e},
<= div>
Why doesn't it make sense for "tu'a", = is it because of the vague "co'e" or because of the embedding= of its argument in a subordinate clause? It has a more complicated structu= re than most LAhE, and its precise meaning depends on context, but it is st= ill a unary function, isn't it?=C2=A0

"ju= 'e" I agree is probably not a binary function if it's supposed= to be the compressed form of ".i". I would say "fa'u&qu= ot; is also in the same boat as "ju'e".=C2=A0
=C2= =A0
but is a bit
strange for {NAhE bo}, and is marginal for {la'e} and {lu'e}, since= the
referent-symbol relation isn't really bijective.
<= br>
"cmima" is not bijective either, so if that was a r= equisite you'd have to include "lu'a" and "lu'i&= quot; among the marginals. which leaves only "lu'o" and "= ;vu'i".
=C2=A0
So relaxing that slightly, we can have qualifiers resp non-logical
connectives interpreted as binary resp ternary relations (which in many
cases are graphs of functions, but we don't require that). There's<= br> a reasonably obvious choice for the relation in every case (even {fa'u}= ,
if we're willing to clutter our universe up with a special data type to=
handle it, which I think should be fine really).

<= /div>
Can "ko'a fa'u ko'e prami vei ro fa'u su'= ;o ko'i" be handled with a special data type?=C2=A0

=
So {LAhE ko'a} -> LAhE(x,ko'a), and we still have to decide how = to
extract a term from this unary predicate. We have the usual options - we can quantify (universally or existentially, plurally or singularly, with various possibilities for the scope), we can take the mereological sum
of the extension (with or without a presupposition that this also
satisfies the predicate), we can take the kind, we can have the speaker
pick something(s) in the extension without further specification
(possibly with some restriction like it having to be somehow salient).
I think that's exhaustive (and so ta'o ru'e I think {lo} must b= e one of
these, or be ambiguous between some of them, cf bottom of this mail).

CLL lojban takes the quantification route. Based on the examples in CLL, it looks like the implicit quantifier is {su'o}.

With xorlo, the natural choice is {lo}.

Yes.=C2=A0

So this gets us (back) to {LAhE ko'a} -> {lo [LAhE] be ko'a}. Maybe even {tu'a ko'a} can be put in that form.

"tu'a ko'a" could be "lo dumco'= e be ko'a", but the problem is that "tu'a su'o ko'= ;a" is supposed to be "lo du'u su'o ko'a co'e&quo= t;, which doesn't work with "dumco'e".=C2=A0
=C2=A0
Then there's the question of what to do with quantifiers and logically<= br> connected sumti. Transparency is the simplest option, since it reduces
us directly to the case we've just dealt with, but it doesn't give = the
desired semantics to {tu'a}.

Sorry, whi= ch case?=C2=A0

Stickin= g to the model described above, the
only alternative seems to be to have the logical operators operate on
the unary predicate, yielding e.g. {LAhE re da} -> {lo poi'i re da z= o'u
LAhE be da}.

I would call this one the = simplest, the one that gives "lu'a ko'a .e ko'e" =3D = "lo cmima be ko'a .e ko'e" rather than "lo cmima be = ko'a ku .e lo cmima be ko'e".=C2=A0
=C2=A0
=
But this *still* doesn't give the desired semantics to {tu'a}.
So we give up on including {tu'a}, and handle it separately.

Right, because "tu'a" was introduce= d precisely to kill the usual "pseudo-term as bridi operator" rul= es, so it is expected that those rules will fail with "tu'a".= =C2=A0

So finally, all we're left with is:
=C2=A0 =C2=A0 1. defining the binary/ternary relation for each word;
=C2=A0 =C2=A0 2. deciding between the two options for handling logical oper= ators;
=C2=A0 =C2=A0 3. deciding whether there should be any other exceptions.

1 is the business of a dictionary, not this thread.

I hope we can agree that the default for 3 should be "no" unless<= br> there's a pressing reason.

"tu= 'a", "fa'u" and "ju'e", or just "= tu'a"?

"fa'u" and "ju&= #39;e" are exceptions in an opposite sense than "tu'a". = Whereas "tu'a" constrains the bridi-operators that it takes a= s arguments to act on a subordinate predicate, "fa'u" and &qu= ot;ju'e" are themselves bridi operators that act on a superordinat= e bridi.=C2=A0

For 2: either choice seems reasonable. I'd prefer transparency just
because it's simpler - but if you think, with {tu'a} entirely ignor= ed,
that it's important to have opaqueness, then I'm happy to accept th= at.
Do you?

I don't agree transparency = is simpler.=C2=A0

Also, to give an argument of the= kind that And would disapprove of, I think that as a general rule sumti-6 = should not be bridi operators, and since LAhE is in sumti-6, it should gene= rate a logical term, not a pseudo-term. This argument doesn't apply to = JOI, which shows up higher up in the grammar.

> > Regarding {lo}: could it be the "down" operator which e= xtracts a kind
> > from a predicate? I'm not seeing any other options, if it is = "definite"
> > and if \iota is out.
>
> That kind of presupposes that among all the various operators that
> linguists/logicians/etc have defined, described, explored there has to= be
> one that matches "lo". I don't know enough about the sub= ject to give an
> opinion one way or the other.

I intended no such presupposition. If it's something already nam= ed and
analysed, that makes things easier, but it isn't necessary. I really honestly meant that I don't see what else {lo} could mean. In the
exhaustive-as-far-as-I-can-see list of plausible ways of extracting
a term from a unary predicate I gave above, if we rule out
quantification, require that the predicate determines the term
("definiteness"), and require that the resulting term satisfies t= he
predicate, then we're left with only these two possibilities:
=C2=A0 =C2=A0 mereological sum of the extension with a presupposition that = this
=C2=A0 =C2=A0 satisfies the predicate (\iota)
or
=C2=A0 =C2=A0 the kind corresponding to the predicate (down).

Am I missing some possibilities?

If one of = these operators gives reasonable meanings to all of these sentences, I woul= d say go for it:=C2=A0

=C2=A0lo ci cukta poi mi tc= idu ca lo ca masti cu cpana lo vi jubme

=C2=A0mi n= elci lo ka limna

=C2=A0mi ca'o pinxe lo djacu<= /div>

=C2=A0lo djacu cu dunja lo ka kelvo li no

=C2=A0lo cipni cu se farvi lo dinsauru

mu'o mi'e xorxes

--
You received this message because you are subscribed to the Google Groups &= quot;lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to lojban+unsub= scribe@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 http= s://groups.google.com/d/optout.
--089e0158c5aab056c005053a5798--