Received: from mail-pz0-f56.google.com ([209.85.210.56]:60182)
	by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76)
	(envelope-from <lojban+bncCOTEtqyUDhDJ7cX2BBoEx1k65A@googlegroups.com>)
	id 1RURiU-0000pX-3o; Sat, 26 Nov 2011 15:31:37 -0800
Received: by pzk6 with SMTP id 6sf1923627pzk.1
        for <multiple recipients>; Sat, 26 Nov 2011 15:31:23 -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=Zea5/xXTxcu0LNWr7QI9sIpzB8IhMc6c8f/1CX0cUXc=;
        b=rdhPPLxplG96B6UgVWQYBcH79IzONrbHQhwA08J/uXU5HkyS4nztK//M0syLbyCXcL
         yZHKtmWBzR8HbOkF50pr5k3Plz7IZ8SqtUpsJXvlUZ+BNvF6/2DpQsMbmObqll/L9bna
         dbIOppoPhWlEKMdz5XsKjlS9Y2XaHssukUln8=
Received: by 10.68.16.161 with SMTP id h1mr1941813pbd.9.1322350281560;
        Sat, 26 Nov 2011 15:31:21 -0800 (PST)
X-BeenThere: lojban@googlegroups.com
Received: by 10.68.26.8 with SMTP id h8ls5474697pbg.1.gmail; Sat, 26 Nov 2011
 15:31:20 -0800 (PST)
Received: by 10.68.0.170 with SMTP id 10mr17520560pbf.2.1322350280951;
        Sat, 26 Nov 2011 15:31:20 -0800 (PST)
Received: by 10.68.0.170 with SMTP id 10mr17520559pbf.2.1322350280943;
        Sat, 26 Nov 2011 15:31:20 -0800 (PST)
Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19])
        by gmr-mx.google.com with ESMTPS id u7si10154649pbn.2.2011.11.26.15.31.20
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sat, 26 Nov 2011 15:31:20 -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 pAQNVKVR017718
	for <lojban@googlegroups.com>; Sat, 26 Nov 2011 23:31:20 GMT
Received: from martin by gonzales.homelinux.org with local (Exim 4.75)
	(envelope-from <mbays@sdf.org>)
	id 1RURiK-0004WN-2e
	for lojban@googlegroups.com; Sat, 26 Nov 2011 18:31:20 -0500
Date: Sat, 26 Nov 2011 18:31:20 -0500
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1
Message-ID: <20111126233119.GC19833@gonzales>
References: <20111126012512.GA6702@gonzales>
 <CAO7tK2euHY7snwkb2L68spGHYpX=mAiVXYYjXs0Aws+3=JZdEQ@mail.gmail.com>
 <20111126040757.GA17974@gonzales>
 <CAO7tK2dJc8y14v8iVZ-3Y7WxW55JJ5-qv4f841aVy=AmxnqJ-w@mail.gmail.com>
 <20111126150912.GB27177@gonzales>
 <CAO7tK2cMYxgWMJWCLL0_WdH25h3nzKDrh9BAKV3_2RQSf2VqFw@mail.gmail.com>
 <20111126171419.GA15113@gonzales>
 <CAO7tK2faJ7SNcepEYg9dXaj7ZNrmH-1Gf6KA=d9O_xLwSu9fAQ@mail.gmail.com>
 <20111126195318.GA19833@gonzales>
 <CAO7tK2fGWvWrDPuNhmtcm1W=M8p_TNz_UC2YSj=dd-XTpE+92Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR"
Content-Disposition: inline
In-Reply-To: <CAO7tK2fGWvWrDPuNhmtcm1W=M8p_TNz_UC2YSj=dd-XTpE+92Q@mail.gmail.com>
X-PGP-Key: http://mbays.freeshell.org/pubkey.asc
X-PGP-KeyId: B5FB2CD6
X-cunselcu'a-valsi: vibna
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: /


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

* Saturday, 2011-11-26 at 17:53 -0300 - Jorge Llamb=EDas <jjllambias@gmail.=
com>:

> On Sat, Nov 26, 2011 at 4:53 PM, Martin Bays <mbays@sdf.org> wrote:
> >
> > Is there any reasoning at all for the current asymmetry?
> >
> > I see no issue at all as far as the semantics goes with allowing "guhek
> > selbri-3 gik selbri-3" and "gek sumti gik sumti". In terms of my code,
> > it would involve changing two characters...
>=20
> I assume it had to do with how they wanted forethought to group with
> respect to afterthought.

Ah yes. It lets you grab the whole of a gek-gik in afterthought.

Well, a pretty minor issue.

> > In other words, I'm interpreting a seltau as giving an implicit
> > subsentence (complete with a prenex to export to), with linkargs
> > becoming tailterms and an analogue of {ke'a} in the x1.
> >
> > Does that seem right?
> >
> > The actual semantics of the resulting Tanru is something I "leave to the
> > pragmatics module", i.e. don't even try to handle for now. But my
> > assumption is that all the data required to interpret the tanru is
> > that I'm giving, i.e. the seltau as a unary predicate and the tertau as
> > a relation.
>=20
> Since you don't say anything about the resulting semantics, why do you
> need the seltau being a unary predicate rather than a relation?

Because I believe this to be what seltau are, i.e. that higher places
are filled with zo'e. Just like in description sumti.

I checked this against the uses of tanru in the CLL.

Having it be any other way would make guessing the meaning of a tanru
even more difficult than it currently is.

> My first impression would be that sometimes the pragmatics module
> might need to use the full relation implicit in the seltau rather than
> just the forced unary predicate.

Hrm. I hope not.

> >> If you have "su'o da" with scope over "gi'e", there is no doubt that
> >> it will also have scope over "na".
> >
> > Actually... no, that isn't how I'm doing it. I have the extra tail terms
> > after the vau distributing over the gi'e conjuncts, appending the tail
> > terms to each, and the result then being interpreted:
> >
> > na broda gi'e na brode vau da
> > -> na broda da gi'e na brode da
> > -> EX x. [ na broda x gi'e na brode x ]
> > -> EX x. (!broda(x) /\ !brode(x))
>=20
> Yuck. So you distribute the *text* "da", and only then consider the
> implicit quantifier?

Not literally the text, but a purely syntactic proxy for it (so 'yuck'
is still a reasonable reaction).

But isn't this how you would handle tailterms when converting to a gek?

I suppose your point is that this leads to less objectionable results.
I can't deny that there's something fairly horrible about {broda gi'e
brode vau na ku} ending up as equivalent to {broda gi'e brode}...

I see one other possible approach: interpret the connected tail terms of
a connected briditail once, but have any resulting sumti be appended to
both bridi. That would sole the {vau na ku} and {vau PA da} uglinesses,
and I don't see any theoretical problems with it. It would, however,
complicate the code quite a bit, suggesting that it isn't very natural.

So... OK, you win.

I'm now handling giheks analogously to eks, giving e.g.

broda da de gi'e brode vau de na ku di
=3D=3D ge broda da de gi brode vau de na ku di
=3D=3D (EX x1. EX x2. !EX x3. broda( ,x1,x2,x2,x3) /\
	EX x1. !EX x2. brode( ,x1,x2)) .

Thanks.

> Does that mean you get a different result for:
>=20
> na broda gi'e na brode vau su'o da

As it happens I didn't, but only because I have {ny da my da} equivalent
to {ny da da} - because I couldn't make any sense of the CLL's
prescriptions for quantifiers on already bound {da}.

Any advice on that?

Martin

--w7PDEPdKQumQfZlR
Content-Type: application/pgp-signature

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

iEYEARECAAYFAk7RdscACgkQULC7OLX7LNZ5LACfT50xBu3sg0Tgy+M1SHaGGixY
+n8AoJmgzoXzxuzatxDekRrRN1vk/s8R
=EYYq
-----END PGP SIGNATURE-----

--w7PDEPdKQumQfZlR--