Received-SPF: none (google.com: mbays@sdf.org does not designate permitted sender hosts) client-ip=192.94.73.24;
Date: Sat, 6 Sep 2014 14:52:08 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] unquantified sumti with restrictive relative clauses in xorlo
Message-ID: <20140906185208.GC8550@gonzales>
References: <20140904043953.GA29601@gonzales>
 <54083D4C.5000809@gmx.de>
 <20140904222640.GD29601@gonzales>
 <CAO7tK2eUfFe6GXXkh8n1Ej7CyAsgLYGbrxJrH9+ZXj6M2=K6EQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB"
Content-Disposition: inline
In-Reply-To: <CAO7tK2eUfFe6GXXkh8n1Ej7CyAsgLYGbrxJrH9+ZXj6M2=K6EQ@mail.gmail.com>
X-cunselcu'a-valsi: jecta
User-Agent: Mutt/1.5.22 (2013-10-16)
X-Original-Sender: mbays@sdf.org
X-Original-Authentication-Results: gmr-mx.google.com;       spf=neutral
 (google.com: mbays@sdf.org does not designate permitted sender hosts) smtp.mail=mbays@sdf.org
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
List-ID: <lojban.googlegroups.com>
X-Google-Group-Id: 1004133512417
List-Post: <http://groups.google.com/group/lojban/post>, <mailto:lojban@googlegroups.com>
List-Help: <http://groups.google.com/support/>, <mailto:lojban+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/lojban
Sender: lojban@googlegroups.com
List-Subscribe: <http://groups.google.com/group/lojban/subscribe>, <mailto:lojban+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+1004133512417+unsubscribe@googlegroups.com>,
 <http://groups.google.com/group/lojban/subscribe>
X-Spam-Score: -1.9 (-)
X-Spam_score: -1.9
X-Spam_score_int: -18
X-Spam_bar: -


--gr/z0/N6AeWAPJVB
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Saturday, 2014-09-06 at 14:41 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:

> On Thu, Sep 4, 2014 at 7:26 PM, Martin Bays <mbays@sdf.org> wrote:
>=20
> >   if
> > {ko'a poi broda} is a referring expression in itself, one might expect
> > {ro ko'a poi broda} to mean
> >     (1)  {ro da poi me ko'a poi broda},
> > but instead we have a separate rule which makes it
> >     (2)  {ro da poi me ko'a gi'e broda},
> > and (1) and (2) agree only in case (iv).
> >
> > They almost agree in case (v), and I'm tempted to amend case (v)
> > to have it give {ro ko'a poi broda} meaning (1) rather than meaning (2).
>=20
> I do think (1) is right and (2) is just a special case. The BPFK formal
> definition has (2), but I think that was just an oversight, not fully
> considering non-distributive predicates. The general definition suggests
> it's (1).  With the assignment "ko'a goi lo tadni" for example, I wouldn't
> have a problem with "no ko'a poi pu sruri lo dinju ba se sfasa" being
> meaningful.

I think you must be right about this.


I'm still not wholly happy with {ko'a poi broda} -> {zo'e noi me ko'a
gi'e broda}, but I'll accept it for now.

> > I'd say the bracketed phrase there has an unbound
> > ("donkey") variable, and we should either consider it an error or
> > universally quantify it out to give
> >     {PA broda noi brode} -> {PA da poi broda zi'e noi brode}
> >     -> {to da brode toi PA da poi broda} *
> >     -> {to ro da brode toi PA da poi broda}
> > or, perhaps, remembering the domain of the variable and only universally
> > quantifying over that, giving
> >     {to ro da poi broda brode toi PA da poi broda} ;
> > but that's a bit of a pain in practice, since the clause giving the
> > domain could itself mention unbound variables, and you have to recurse.
>=20
> "PA broda noi brode" and "PA da noi brode" are just weird, since they don=
't
> provide any referents for the relative clause to be about. They're almost
> as bad as "zi'o noi brode". When they are used it's because we are thinki=
ng
> of quantifiers as determiners rather than as pure quantifiers.

Yes, weird, and probably mistakes. Really the reason I want to handle
them as described above is because it fits nicely with the "Skolem
function" approach to handling externally bound variables in
a description clause, as in
    {ro da broda lo brodi be da}
    -> {ro da broda zo'e noi brodi da}
    -> {to cy brodi da toi
	ro da broda cy} *
    -> {to ro da li ma'o fy mo'e da brodi toi
	ro da broda li ma'o fy mo'e da}

(and again, if it had been {ro da poi brodu cu broda zo'e noi brodi da},
maybe the quantifier in the bracket should really have domain brodu(_)
too). Not really relevant.

Martin

--gr/z0/N6AeWAPJVB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlQLV9gACgkQULC7OLX7LNYJDQCcCljW2C3Bmc58RJD2XGYrur5G
7fIAoOA6Te6Djj1MpwtH1u8oR7EZkCeH
=qInj
-----END PGP SIGNATURE-----

--gr/z0/N6AeWAPJVB--