[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lojban-beginners] search for happiness. {sisku lo selgleki} or {sisku lo ka selgleki}?
On 12 February 2013 02:00, Jacob Errington <nictytan@gmail.com> wrote:
> On 10 February 2013 14:43, Felipe Gonçalves Assis <felipeg.assis@gmail.com>
> wrote:
>>
>> doi tsani
>>
>> I see things a bit different. I believe that kakne2 and djica2 should
>> be abstracts
>> ({ka} and {du'u}), but for their intensionality. gleki2, on the other
>> hand, is as
>> concrete an event as it can be, not an abstract property or
>> proposition. Consider
>> {mi gleki so'i lo nu mi klama lo zdani be mi}
>>
>
> Actually, quantifying over events like that has various problems, namely
> that the zo'e inside it are magically changing. In Lojban, every event is
> unique, but as humans we roll them together.
> In reality, what's happening when you quantify over an event like that, you
> want to make a whole bunch of slightly different events: the event of going
> home on Monday, and the one of Tuesday, and the one on Wednesday, etc. Each
> of these events in unique.
> It seems like a predicate logic sentence would be best to describe this, and
> ultimately moves the quantifier scope higher: {.i so'i da zo'u mi gleki lo
> ka klama lo zdani ca da} "For many X, I am happy to go home at X." This
> ultimately creates many properties of going home, for each of which it is
> asserted that the speaker is happy about that.
>
Then you should agree that quantifying over red things is equally
problematic, because each red thing is unique, so that instead of
{mi citka so'i da poi xunre}
we would have something like
{so'i de zo'u mi citka lo xunre be sela'u de}
or, using your idea of space-time,
{so'i de zo'u mi citka lo xunre be bu'u de}
We are used to talking about different sunsets as well as about
different red things. We understand that each sunset is slightly
different from the other, as we understand that each red thing is
slightly different from the other, but that does not stops us from
describing them with a common predicate, as well as counting them. I
see nothing illogical in that.
Anyway, you've made your point that limitedness of expression is not a
problem, but see last paragraph.
>>
>> Also, your
>> {mi gleki lo ka se li'i do citka lo plise} instead of
>> {mi gleki lo nu do citka lo plise}
>> is like
>> {mi klama lo stuzi be lo zdani be mi} instead of
>> {mi klama lo zdani be mi}
>> or
>> "I saw an image of the sun setting" instead of
>> "I saw the sun setting",
>>
>> This extreme typing of sumti places just creates hindrances in
>> expression without
>> adding anything to the speaker's or listener's understanding of the
>> world. I already
>> know that it is my experience of an event that can bring me happiness
>> about it,
>> not somebody else's, and that what determines whether someone is tall or
>> short
>> is his/her body, not his/her friendliness.
>
>
> As I explained, the general benefit of making places infinitive-places with
> {ka} is to make jvajvo more commonplace. As it stands, we frequently drop
> "repeated" places that it would be nice to still have. Reconsider my
> examples of {ctidji}. Using current nu-based djica, there is no way to get
> both meanings in separate lujvo. Making the lujvo always drops the other
> one. If we define ctidji with a place merger, we can't recover ctidji
> without that merger.
> ctidji = x1 djica lo nu x1 citka x2 ...
> or
> ctidji = x1 djica lo nu x2 citka x3 ... ?
> Defining one makes the other undefinable, whereas with infinitives, we just
> have to throw in -fri- to get the other meaning:
> ctidji = x1 djica lo ka ce'u citka x2 ...
> and
> ctifridji = x1 djica lo ka ce'u lifri lo li'i x2 citka x3 ...
>
> I agree, it creates some boilerplate if you want to say something like "I
> want you to eat an apple," but there're ways to circumvent this. In fact, I
> frequently use this tanru trick to avoid using {lo nu} and {lo ka}: {.i mi
> djica co li'i do broda}. This has the unfortunate disadvantage of making it
> impossible to assign djica3 (or explicitly assign djica2, although tanru
> inference tells us that {lo ka se li'i do broda} is djica 2).
>
{djica} is a different discussion. I too disagree that a {nu}-clause
makes sense in djica2. Your {ko'a djica ko'e} is just my {ko'a djica
lo du'u ko'a ckaji ko'e}, and my {ko'a djica ko'e} is your {ko'a djica
lo ka lifri su'o fasnu be ko'e}.
I just think that, if you accept that wanting people to live in peace
in the next century can be paraphrased as wanting to lifri that, you
have made the definition of {lifri} almost vacuous.
> (The choice of li'i and lifri in general for more flexibility in the rigid
> infinitive system requires that the actual association between the lifri1
> and lifri2 possibly be extremely vague, which isn't exactly a problem.)
>
Yeah, you appear to agree. Don't you find it ugly?
Besides, you don't have to ka-ify djica2 to get jvajvo for the
infinitive interpretations. Dependent places in lujvo is a common
issue that has to be dealt with anyhow, and other more general and
less invasive solutions exist.
If you want {rodydji} to be strictly reserved to {ko'a djica lo du'u
ko'e broda} under the {du'u} definition of {djica}, we could have
{rodydjisi'u} for {ko'a simxu lo ka ce'u djica lo du'u ce'u broda}.
Another option is to be liberal about djica2, allowing both properties
and propositions, and then making the distinction via {kambrodykezdji}
vs {dumbrodykezdji}, which would be even more regular lujvo.
> As for your comparison between {gleki lo ka se li'i broda} and {klama lo
> stuzi be ko'a} isn't entirely rational. The "speech cost" of {ka se li'i}
> versus the introduction of a whole other selbri and linked arguments is
> completely different. {ka se li'i} versus {nu} is only 3 syllables (short
> syllables with no consonant clusters) longer. (At most four, if you include
> the extra kei.) Also, I find it much easier to understand a compound
> abstractor like this than complex linked arguments.
Speech cost is the least. The complexity of the object is the problem.
It is only easy to handle when it is part of a set phrase, such as
{ko'a gleki lo ka se li'i broda}. I made the argument because I
thought you wanted to emphasize the experience as the source of
happyness. Now I see that the experience is for you just a way of
getting an extra place to fit the {ce'u} of an uncalled for property.
> Also, stuzi1 and stuzi2 are arguably *the same thing*, which can be
> troubling...
> Now, if stuzi1 and stuzi2 are argubly the same thing, then {mi klama lo
> stuzi be ko'a} and {mi klama ko'a} are also arguably the same thing.
> However, under my infinitives system, events are not interchangeable with
> ka-abstractions, and there is no way to define an equivalency as I have in
> the case of stuzi.
>
I agree, and hold my point. Besides the counting, I believe events can
also be pointed to, and may fill places for both time and space
(although, like objects that have more clear limits in space than in
time, events usually are more clearly delimited in time rather than in
space).
Here your {ko'a gleki ko'e} is my {ko'a gleki lo nu ko'a ckaji ko'e},
and my {ko'a gleki ko'e} is your {ko'a gleki lo ka lifri ko'e}. The
problem is that you have unnecessarily put an essentially concrete
object (the event) under an intensional scope (the property). Nothing
stops us from doing that as much as we can. For example, we could
define {citka} to mean "x1 eats something with property x2", rendering
{mi citka lo ka plise} instead of {mi citka lo plise}. This would make
the lujvo {plisycti} represent the same structure as {volka'e}, but
that is, I repeat, ugly, and complicates things, not on the
syllable-count level, but on the grammatical one.
mu'o
mi'e .asiz.
--
You received this message because you are subscribed to the Google Groups "Lojban Beginners" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lojban-beginners+unsubscribe@googlegroups.com.
To post to this group, send email to lojban-beginners@googlegroups.com.
Visit this group at http://groups.google.com/group/lojban-beginners?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.