Received: from mail-pz0-f61.google.com ([209.85.210.61]:55258) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RWz50-0002Ci-OL; Sat, 03 Dec 2011 15:33:21 -0800 Received: by dajx4 with SMTP id x4sf2900860daj.16 for ; Sat, 03 Dec 2011 15:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to:x-pgp-key :x-pgp-keyid:x-cunselcu'a-valsi:user-agent:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe; bh=n4ecQqsqeSR0NO+CuLjWz9S8y7xWhTlMW/zo36k8n5E=; b=DfXgKHpJLuf2btnBSWNItu5r5FQFDTH8K5NXOJj05xRTyVMtlWQbf2JckdElF3Vyzl 2/Z64oEkrOWd31yi5ymsAQ4nRiw3S7s4TwCgOYnHmgoaROu3BD8m4V+LvaKMQc+oD/Eu MBosAUz22Igf3Wfn4sX5Mm32jTLtEav/vorSw= Received: by 10.68.14.135 with SMTP id p7mr1849415pbc.5.1322955184669; Sat, 03 Dec 2011 15:33:04 -0800 (PST) X-BeenThere: lojban@googlegroups.com Received: by 10.68.26.8 with SMTP id h8ls19227403pbg.1.gmail; Sat, 03 Dec 2011 15:33:04 -0800 (PST) Received: by 10.68.15.41 with SMTP id u9mr16380996pbc.3.1322955183999; Sat, 03 Dec 2011 15:33:03 -0800 (PST) Received: by 10.68.15.41 with SMTP id u9mr16380995pbc.3.1322955183987; Sat, 03 Dec 2011 15:33:03 -0800 (PST) Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19]) by gmr-mx.google.com with ESMTPS id u7si17722111pbn.2.2011.12.03.15.33.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Dec 2011 15:33:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of mbays@sdf.org designates 192.94.73.19 as permitted sender) client-ip=192.94.73.19; Received: from gonzales.homelinux.org (root@sverige.freeshell.org [192.94.73.4]) by sdf.lonestar.org (8.14.5/8.14.3) with ESMTP id pB3NX3dU000769 for ; Sat, 3 Dec 2011 23:33:03 GMT Received: from martin by gonzales.homelinux.org with local (Exim 4.75) (envelope-from ) id 1RWz4p-0008TD-3G for lojban@googlegroups.com; Sat, 03 Dec 2011 18:33:03 -0500 Date: Sat, 3 Dec 2011 18:33:03 -0500 From: Martin Bays To: lojban@googlegroups.com Subject: Re: [lojban] semantic parser - tersmu-0.1rc1 Message-ID: <20111203233303.GB11790@gonzales> References: <20111129030444.GA26300@gonzales> <20111129225808.GA19818@gonzales> <20111201021703.GL2886@gonzales> <20111203175028.GC12482@gonzales> <20111203204015.GA11790@gonzales> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://mbays.freeshell.org/pubkey.asc X-PGP-KeyId: B5FB2CD6 X-cunselcu'a-valsi: sirxo User-Agent: Mutt/1.5.21 (2010-09-15) X-Original-Sender: mbays@sdf.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of mbays@sdf.org designates 192.94.73.19 as permitted sender) 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: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: Sender: lojban@googlegroups.com List-Subscribe: , List-Unsubscribe: , X-Spam-Score: -0.0 (/) X-Spam_score: -0.0 X-Spam_score_int: 0 X-Spam_bar: / --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Saturday, 2011-12-03 at 19:06 -0300 - Jorge Llamb=EDas : > On Sat, Dec 3, 2011 at 5:40 PM, Martin Bays wrote: > > * Saturday, 2011-12-03 at 15:51 -0300 - Jorge Llamb=EDas : > >> What about things like: "ro da poi verba cu prami lo mamta be da"? > > Ah, you mean because {ro mamta be da} would get everything which is > > motherly towards {da}, when we might want to specifically mean the > > biological mother but not want to waste a couple of syllables by making > > it {ro rorci mamta be da}? >=20 > I could just as well have said "ro da poi verba cu pencu lo nazbi be > da". It didn't occur to me you would think the version with "ro" was > more clear. No more or less clear in that case... if we assume that there's only one nose per da, then I don't see any difference between {lo}, {ro}, {piro}/{ro'oi}, {su'o} or {piza'u}/{su'oi} here. Arguably, {lo} is a little misleading, as it asks you to use pragmatics when there's no need for it - it might lead you to expect that some unusual metaphorical meaning of nazbi was in use. > > I suppose that is an example. Although the complication in semantics > > involved seems rather large compared to this two-syllable saving... > > generally, those situations in which it's reasonable to leave the nature > > of a function to pragmatics seem to coincide with those in which it's > > easy to actually express it. But maybe it seems that way only because > > the examples I'm considering are too simple. >=20 > How about a non-distributive case: >=20 > ro da poi verba cu pilno lo re xance be da lo nu kavbu lo bolci {ro da poi verba cu pilno pi ro xance be da [ku noi re mei ku'o] lo nu kavbu lo bolci} s/pi ro/ro'oi/ if you prefer. Now you could say that the above could just as well be {...lo nu da kavbu lo bolci}, and then we again have a non-constant lo-phrase. You'd be right, and I'm not sure what quantifier to replace that {lo} with, because I'm not sure what that {lo nu} is getting. If it's a bunch of events, then {pi su'o}/{su'oi}; if it's a kind - I guess you'd use {su'o}, while I would want some other quantifier for it, but I don't know what. But that's kind of beside the point! > >> >> "ge da gi ko'a da broda" > >> >> > >> >> (1) ge su'o da su'o de zo'u da de broda gi su'o de zo'u ko'a de bro= da > >> >> > >> >> (2) su'o da zo'u ge da da broda gi ko'a da broda > > > >> > (1) seems reasonable. It looks like it could be implemented (in all > >> > cases) by having the binding of a {da} in a connectand to the bound > >> > variable it creates survive only within the connectand. I think I mi= ght > >> > like it. > >> > >> That's what makes sense to me, but of course it goes against CLL. > > > > Really? Explicitly? >=20 > Who knows? This is the closest I can find: >=20 > http://dag.github.com/cll/16/10/ >=20 > << > 10.3) mi .enai do prami roda > I, and not you, love everything. > expands to: > 10.4) mi prami roda .ijenai do prami roda > I love everything, and-not, you love everything. > and then into prenex form as: > 10.5) roda zo'u mi prami da .ije naku zo'u do prami da > For each thing: I love it, and it is false that you love (the same= ) it. > >> >=20 > 10.5 is actually ungrammatical. Presumably the second "zo'u" is > a typo, although this section is about moving a negation to the > prenex, so... Quite. I've basically been ignoring this section, because it seems to be working with a grammar in which each sentence has a prenex - which is contrary to the official grammar, and which wouldn't fit with specification elsewhere to the effect that {PA da} has scope over the whole statement (when not inside a subsentence). > Can you extract a rule from that for how connectives are supposed to > interact with quantifiers? I don't think I can. >=20 > (2) > >> How else can you process CLL's implicit quantifiers having scope over > >> several bridi? > > > > I'm not sure what you're getting at here. As I read CLL, the first {da} > > in a statement/subsentence is "exported" to the prenex, >=20 > But before or after dealing with "ge"? There isn't a single "the > prenex" to consider: >=20 > (prenex1) ge (prenex2) da da broda gi (prenex3) ko'a da broda Once we've got that far, I think it's clear. The two subsentences are handled separately - i.e. can, donkey anaphora aside, be handled in either order - each producing a proposition. So there must be two existential quantifiers here, one for each subsentence. --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7asa8ACgkQULC7OLX7LNa16ACg1Mr0fvfm9VNkoShi4xFWB5BS T/QAn2PY90PWNG03f2hejL+kWnEDI37/ =zWmu -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv--