[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lojban] semantic parser - tersmu-0.1rc1



Typically, you have either to use Polish notation or to have a convention about 
the same variable in several bridi.



----- Original Message ----
From: Jorge Llambías <jjllambias@gmail.com>
To: lojban@googlegroups.com
Sent: Sat, December 3, 2011 12:51:13 PM
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1

On Sat, Dec 3, 2011 at 2:50 PM, Martin Bays <mbays@sdf.org> wrote:
> * Thursday, 2011-12-01 at 18:53 -0300 - Jorge Llambías <jjllambias@gmail.com>:
>> On Wed, Nov 30, 2011 at 11:17 PM, Martin Bays <mbays@sdf.org> wrote:
>> >
>> > Meanwhile,
>> > (ii) if {da} is already quantified, then {lo broda be da} is interpreted
>> >    as a skolem function.
>>
>> If da is bound by a quantifier and "lo broda be da" occurs within the
>> scope of the quantifier, yes.
>
> Thinking about it, I'm no longer so convinced that this is important.
>
> I can't think of nor find any examples of uses of {lo broda be da} where
> the itended meaning wouldn't be given more clearly by using {ro} or
> {piro}/{ro'oi}, or occasionally some other quantifier.

What about things like: "ro da poi verba cu prami lo mamta be da"?

> It would certainly be conceptually neater to do away with this "Skolem
> function" possibility for description sumti - declare them to be
> *literally* constants, with any {da} in the description assumed not to
> be bound outside, and any anaphora to exterior variables (or connected
> terms) considered erroneous.
>
> See any compelling arguments against that?

I don't really see a problem with functions. (I don't think they are
Skolem functions though, just the usual functions of first order
logic.)

>> But I don't think you need to bring "lo" into this. We already have
>> the same issue with "ge da gi ko'a da broda", which could be either
>> of:
>>
>> (1) ge su'o da su'o de zo'u da de broda gi su'o de zo'u ko'a de broda
>>
>> (2) su'o da zo'u ge da da broda gi ko'a da broda
>
> Hmm. I have it as
>
> (3) ge su'o da zo'u da da broda gi su'o da zo'u ko'a da broda
>
> , i.e. handling the two arms of the connective separately. This
> algorithm seems most natural to me. Do you dislike this possibility for
> some reason other than the {lo broda be da} issue?

I find it weird that for one conjunct the second "da" is the same
variable as the first "da", and for the other conjunct it's a
different variable. As I said, I don't think bridi connected with eks
share words.

> (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 might
> like it.

That's what makes sense to me, but of course it goes against CLL.

>> Is "da" just equivalent to "su'o da" in the same position where
>> it first occurs (in which case the scope of "su'o" is determined by
>> this position only) or is "da" bound by a quantifier with scope wide
>> enough to encompass all following occurrences of "da" (in which case
>> it may not be equivalent to "su'o da" in the same position)?
>
> Interesting idea. This is how you derive (2)?

That's the only way I can make sense of CLL's rule for implicit
quantifiers jumping out of their "natural" scope.

> But having such a preprocessing step before scope can be decided
> - meaning that in speech, the scope of a heard {da} can't be determined
> until the statement is finished - strikes me as something to be avoided
> if possible.

How else can you process CLL's implicit quantifiers having scope over
several bridi?

mu'o mi'e xorxes

-- 
You received this message because you are subscribed to the Google Groups 
"lojban" group.
To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to 
lojban+unsubscribe@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/lojban?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.