Received: from mail-pz0-f56.google.com ([209.85.210.56]:59102)
	by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76)
	(envelope-from <lojban+bncCOTEtqyUDhCfzMH2BBoENOUuhw@googlegroups.com>)
	id 1RU9Yd-0007pK-Hm; Fri, 25 Nov 2011 20:08:13 -0800
Received: by pzk6 with SMTP id 6sf797485pzk.1
        for <multiple recipients>; Fri, 25 Nov 2011 20:08:01 -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=xGsb33Nte00d7pH5zBIXGq4CxKZVc9sxAMKUmBlBrug=;
        b=Vha5s+jUxPVeqe0mYHURqewHcLYSw4KFIfMnNkxfgKACXZyykVl+iX8rpZkxTxwmDi
         bU4LN/yiH5RM1dgC7+AW78i9eTqbtjoELZxb9wkRyffT1kmUhV+8LJoGV54lGZUgbwom
         bJelUfGTQOjnGFCDLQN87qs69v9rdi5DwVjvE=
Received: by 10.68.54.200 with SMTP id l8mr28479pbp.7.1322280479091;
        Fri, 25 Nov 2011 20:07:59 -0800 (PST)
X-BeenThere: lojban@googlegroups.com
Received: by 10.68.121.5 with SMTP id lg5ls5102879pbb.5.gmail; Fri, 25 Nov
 2011 20:07:58 -0800 (PST)
Received: by 10.68.36.6 with SMTP id m6mr13521989pbj.4.1322280478503;
        Fri, 25 Nov 2011 20:07:58 -0800 (PST)
Received: by 10.68.36.6 with SMTP id m6mr13521987pbj.4.1322280478486;
        Fri, 25 Nov 2011 20:07:58 -0800 (PST)
Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19])
        by gmr-mx.google.com with ESMTPS id j5si4847967pbi.0.2011.11.25.20.07.58
        (version=TLSv1/SSLv3 cipher=OTHER);
        Fri, 25 Nov 2011 20:07:58 -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 pAQ47v6w016706
	for <lojban@googlegroups.com>; Sat, 26 Nov 2011 04:07:58 GMT
Received: from martin by gonzales.homelinux.org with local (Exim 4.75)
	(envelope-from <mbays@sdf.org>)
	id 1RU9YT-0002ul-GS
	for lojban@googlegroups.com; Fri, 25 Nov 2011 23:07:57 -0500
Date: Fri, 25 Nov 2011 23:07:57 -0500
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1
Message-ID: <20111126040757.GA17974@gonzales>
References: <20111124044118.GF6112@gonzales>
 <CAO7tK2cfhJtrvLX1S6Mga_CJU2nLyt96_4DR=ygJksH3ixaamg@mail.gmail.com>
 <20111125195038.GA29512@gonzales>
 <CAO7tK2ezxrDKHEDQx1k7O1+E_FsviPXYOK=R8aU3xVy2C4kb6g@mail.gmail.com>
 <20111126012512.GA6702@gonzales>
 <CAO7tK2euHY7snwkb2L68spGHYpX=mAiVXYYjXs0Aws+3=JZdEQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62"
Content-Disposition: inline
In-Reply-To: <CAO7tK2euHY7snwkb2L68spGHYpX=mAiVXYYjXs0Aws+3=JZdEQ@mail.gmail.com>
X-PGP-Key: http://mbays.freeshell.org/pubkey.asc
X-PGP-KeyId: B5FB2CD6
X-cunselcu'a-valsi: jbari
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: <lojban.googlegroups.com>
X-Google-Group-Id: 1004133512417
List-Post: <http://groups.google.com/group/lojban/post?hl=en_US>, <mailto:lojban@googlegroups.com>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:lojban+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/lojban?hl=en_US>
Sender: lojban@googlegroups.com
List-Subscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+subscribe@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+unsubscribe@googlegroups.com>
X-Spam-Score: -0.7 (/)
X-Spam_score: -0.7
X-Spam_score_int: -6
X-Spam_bar: /


--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Friday, 2011-11-25 at 23:13 -0300 - Jorge Llamb=EDas <jjllambias@gmail.co=
m>:

> On Fri, Nov 25, 2011 at 10:25 PM, Martin Bays <mbays@sdf.org> wrote:
> >
> > On second thoughts, I think I agree with your interpretation of the
> > english. It should be read as making two claims: firstly that precisely
> > two of the boys carried their bags on their heads, and secondly that
> > those two bags contained the corresponding lunches.
> >
> > But I think this reading is only permitted because the quantifier
> > effectively picks out a particular group; had it been "two or more of
> > the boys carried his bag, which contained his lunch, on his head", we
> > wouldn't know for which boys the incidental claim is being made.
>=20
> If ke'a can pick "the two that ..." it can just as well pick "the two
> or more that ..."
>=20
> The problem cases are no, ro, me'i and any other quantifier compatible
> with no, because there may be nothing for the relative clause to be
> about. In those cases, the only reasonable choice seems to be the
> whole domain of the quantifier, and if that's the case for those, that
> may have to be the case for all other quantifiers too.

Hmm. This is seeming rather complicated.

It seems related to donkey anaphora - consider
{ro te cange poi ponse su'o xasli noi ke'a xi re darxi cu broda}.


Also, note that the scope-respecting rules sometimes are the most
intuitive - e.g. in {ro da prami de noi se prami da}. I'm not sure what
the scope-breaking rules would make of that; I guess something
nonsensical.

> >> > The obvious alternative would be to have {na broda} work like {broda=
 be
> >> > na ku},
> >>
> >> Isn't that what you are doing though?
> >
> > No; I currently have bare {na} (and presumably other selbri tags, once
> > they're implemented) getting tight scope, within all tail terms, while
> > the scope of tag-terms like {na ku} respects the order of terms.
>=20
> But what do you do when "broda be naku" is a seltau?

I have the negation constrained to the seltau.

I'm understanding a seltau as a unary predicate; in e.g. {broda be na ku
bei ko'a brode}, the seltau is "!broda(_,ko'a)"; in e.g. {broda be da
bei na ku bei de brode} (assuming neither {da} nor {de} are already
bound), it's "EX x1. !EX x2. broda(_,x1,x2)".

> I think it's "broda be na ku" that must force tight scope.

I don't see why.

> For bare "na" (and any other tag) I just follow the general rule of
> left having scope over right. Anything within either bridi tail must
> be within the scope of "gi'e".

But in {broda da gi'e brode da}, the first {da} is to the left of the
{gi'e}. So why shouldn't the {gi'e} be in the scope of the {[su'o] da}?

> > Relatedly, what do you make (assuming you're not allowed to change the
> > official grammar, so there's only one prenex involved) of
> > {na ku broda .i je na ku brode}?
>=20
> ge na ku zo'u broda gi na ku zo'u brode

So do you also have {da broda .i je da brode} -> {ge da broda gi da
brode}? If so: that's clearly contrary to CLL (and much usage). If not:
why not?

> > Hmm. Do I correctly deduce from all this that your rule is to
> > syntactically transform giheks to geks, then interpret those?
>=20
> Yes, but only after all leading terms have been prenexed.
>=20
> > That creates new prenices, which is something I've avoided doing.
>=20
> So your rule is that when a prenex would be allowed by the grammar,
> then it is somehow there, even if it's invisible?

Yes, precisely.

> In that case, if you do end up transforming "gi'e" into "ge", you have
> created a new prenex, whether you want to use it or not.

But I don't transform it to {ge} - I transform it to "/\".

> > I think of giheks as parallel to ijeks.
>=20
> I think of all logical connectives as variants of geks
>=20
> > If we want geks, we can always use geks!
>=20
> You do end up with nothing but geks anyway.

Well. We end up with something which can be expressed in terms of geks.

I don't think we should feel compelled to route our interpretation of
lojban via syntactic transformations to a simplified lojban form.

> >> =A0 ko'a .e ko'e broda su'o da
> >>
> >> In all cases "su'o da" is under the scope of a preceding operator.
> >
> > I certainly agree on the last three. But that's because I have
> > quantified/connected terms, and tag-terms, exporting to the closest
> > prenex, in order.
>=20
> How does that work for ".e"? It seems that if you do what I do, you
> end up exporting "su'o da" to newly created preneces.

In a sense, yes; e.g.

da ko'a .e ko'e de broda
Prop: EX x1. (EX x2. broda(x1,ko'a,x2) /\ EX x2. broda(x1,ko'e,x2))

; but I think of this as exporting the connective to the prenex, and
then the inner existential to that same prenex within the scope of the
connective. Exporting connectives is entirely parallel to exporting
quantifiers (and in a simple case like this, we can even think of it as
literally exporting a universal quantifier over the set {ko'a,ko'e},
although that doesn't work in general).

Basically: when parsing, we always have a notion of 'current prenex',
which corresponds to the closest instance of 'statement' or
'subsentence' we're below. All sumti connectives, termset connectives,
quantifiers and tagged terms (currently just {naku}) export to that
prenex, in order.

Martin

--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature

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

iEYEARECAAYFAk7QZh0ACgkQULC7OLX7LNbEFQCgky3uFDc6AB2fKG5KFFWn04ke
tHEAoMJa/8KPIvhKGIYdTcM96kweDywN
=kZMa
-----END PGP SIGNATURE-----

--+QahgC5+KEYLbs62--