Received-SPF: pass (google.com: domain of seladwa@gmx.de designates 212.227.17.22 as permitted sender) client-ip=212.227.17.22;
Message-ID: <54083D4C.5000809@gmx.de>
Date: Thu, 04 Sep 2014 12:22:04 +0200
From: selpa'i <seladwa@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: lojban@googlegroups.com
Subject: Re: [lojban] unquantified sumti with restrictive relative clauses in xorlo
References: <20140904043953.GA29601@gonzales>
In-Reply-To: <20140904043953.GA29601@gonzales>
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Spam_score: -1.9
X-Spam_score_int: -18
X-Spam_bar: -

la'o me. Martin Bays .me cusku
> Recall the following production:
>
> sumti5 <- quantifier? sumti6 [relative-clauses]
>
> I want to understand the semantics of this in the case that there is no
> quantifier, and there is a restrictive clause among the relative clauses.
> {ko'a poi broda}, in other words.
> [...]
> I can see six broad approaches to interpreting such expressions, i.e. those of
> the form {ko'a poi broda}.
>
> (i) Consider it an error, or just ignore any restrictives.

I don't like this option, because it would be an exception. I believe 
{poi} can be defined in such a way that the same rule handles both 
quantified and unquantified sumti.

> (ii) Declare that in this case (and this case alone), there is an implicit
>      quantifier after all.

This is certainly how if feels at times, but it's probably not necessary 
for it to actually be the case at a formal level.

By the way, the case of {lo broda poi brode ku'o ku} needs to be looked 
at as well. An outer quantifier wouldn't affect the {poi} clause here, 
but it still needs to be defined what it means and how it differs from 
{noi}.

> (iii) Have it pick out some referents such that they satisfy the restrictives:
>      ko'a poi broda -> zo'e noi me ko'a gi'e broda

This is pretty much my take on it. I like the general definition of {poi 
broda} == {je poi'i* broda} because it works in all cases, both with 
sumti and with selbri, and it doesn't matter if there are quantifiers 
present. (it is equivalent to your definition, but works better in real 
life as an afterthought, not that that's very relevant here)

> (iv) Have it pick out those referents which each satisfy broda:
>      ko'a poi broda ->
>          zo'e noi ro da zo'u go da me ke'a go ge da me ko'a gi broda

I think this doesn't fit with the current system where the argument 
places of predicates aren't defined as distributive or collective (they 
should be in my opinion).

If you want distributive satisfaction, {ko'a poi ro ke'a broda} works.

> (v) Something along the lines of (iv), but more in line with plural logic /
>      mereology, perhaps by requiring the obvious maximality condition, i.e.
>      ko'a poi broda ->
>          zo'e noi ge ge me ko'a gi broda gi ro da poi ge ge ke'a xi re me ke'a gi
>          ke'a me ko'a gi ke'a broda cu du ke'a
>      , perhaps making it an error if there is no unique such maximum, or
>      perhaps taking all the maxima together (i.e. taking the join).

This is also a bit too specific, like (iv).

> (vi) Something along the lines of (v), but with no formal rule - just an idea
>      that the intended referents of {ko'a poi broda} are picked out among the
>      referents of {ko'a} by virtue of their brodaing.

Isn't this similar to (iii) as well?

> The usage I've seen could fit any of (iii)-(vi), I think. So, taking various
> degrees of liberty, could CLL's use of restrictives - although of course they
> had implicit quantifiers, so are not really relevant.

There is definitely a lot of contrasting usage between {ko'a poi} and 
{ko'a noi}, with meaningful distinctions being felt by the speakers. 
That, and the fact that I think the general definition of {poi} in terms 
of {je} (or gi'e) works made me believe that something like (iii) is the 
most practical solution.

We could try to write up a table of all the cases:

ko'a poi broda	
	lo me ko'a je poi'i broda / zo'e noi me ko'a gi'e broda

PA ko'a poi broda
	PA me ko'a je poi'i broda / PA da poi me ko'a gi'e broda

ko'a noi broda
	ko'a (to ri broda toi)

PA ko'a noi broda
	PA ko'a (to ri broda toi)

lo broda poi brode
	lo broda je poi'i broda / zo'e noi broda gi'e brode

lo broda noi brode
	lo broda noi brode / zo'e noi broda (to ri brode toi)

(and {lo broda ku NOI} are the same as {ko'a NOI}, as noted)

lo PA broda poi brode
	lo PA broda je poi'i brode
	zo'e noi broda gi'e brode gi'e PA mei

lo PA broda noi brode
	lo PA broda (to ri brode toi)

So a lot of these are equivalent as long as no quantifier is added, but 
they all use the same expansions which work whether or not there is a 
quantifier (or so I hope, let's look for mistakes!).

Oh, there is also {PA broda NOI}:

PA broda poi brode
	PA broda je poi'i brode / PA da poi ke'a broda gi'e brode

PA broda noi brode
	PA da (to ri broda toi) poi ke'a broda

Some of this depends on {ri}'s ability to repeat {da} and quantified 
terms. Writing {PA da (to da broda toi)} would be weird, as the {da} 
could just as well be a new variable.

Anyway, my general idea here was to attach {poi} directly to the selbri 
when possible (using {je poi'i}). When that doesn't work, the sumti 
needs to be turned into a selbri, but with quantified terms that is 
already part of xorlo's definition (PA ko'a == PA me ko'a).

mi'e la selpa'i mu'o

--
* {poi'i} (http://jbovlaste.lojban.org/dict/poi%27i) is an old idea 
which has gained some popularity more recently. I personally consider it 
a great cmavo with a lot of utility and have suggested giving it a 
normal cmavo form (*cough*voi*cough*)

-- 
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.