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

Re: some outstanding issues



Hu'tegh! nuq ja' Logical Language Group jay'?

*Finally* tracked the thread down. The thread was the necessity for a rafsi
for jai.

=>Yes, I was mainly thinking of its standalone uses, things like:

=>jazbai  (jai bapli)     x1(agent) forces x2 to happen by force x3
>
=>and many other selbri that have causative events in x1 but usually
=>make sense with an agent there. {-gau} is not very good for this
=>because it leaves the causative event in x2, and often that's
=>not the best order.

=This is a problem with the lujvo-making rules then, because I would tend
=to delete the causative event, or shift it to the end - which is exactly
=what I think you have done in your examples above.

Jorge responded to Lojbab why the lujvo-rules have to have this problem.
I'll recast this, to drive the point home.

Lujvo can have *a priori* any place structure you want; Jim Carter, in his
own Loglan variant and in Lojban, was of the opinion that such absolute
freedom was undesirable. I came to share that belief. Lojban has no case
system, and only optionally uses a prepositional system. For newly-minted
lujvo, there would be no way of knowing what the fourth or third argument
meant, short of learning distinct dictionary entries for each lujvo.

This would make the Lojban lujvo system impossible to bootstrap; so instead,
it seemed to us preferable to exploit regularities already discernable in
lujvo. Jim Carter conceived the kernel of these; I elaborated it into a
loose algorithm. This algorithm is quite far from fixing the place structure
of any lujvo, but it does greatly limit the possible structures it can have.

The rules I set down, which are intended to allow Lojbanists to guess readily
the plac structure of an unfamiliar lujvo, were the following:

The places of a lujvo must be a subset of the places of its component
gismu (veljvo). Otherwise, we would have an unworkable open set of places
for all lujvo.

The ordering of the places of a lujvo should reflect the ordering of the
places in the expanded veljvo --- that is, of a veljvo with no tanru:
each brivla in the expanded veljvo should be a gismu.

Due to this restriction, there are only four operations you can perform
on the place structures of the veljvo, to get that of the lujvo:

* coreferencing; eg. .abu djica lenu by. viska cy. -> .abu djica lenu .abu
viska cy.;

* concatention; eg. .abu caxno by. cy. dy. gi'e barda .ebu fy. ->
.abu caxybra .ebu fy. by. cy. dy.;

* interpolation; eg. .abu djica lenu .abu viska by. kei cy. -> .abu viskydji
by. cy. ; and

* deletion; eg. .abu djica lenu .abu viska by. zo'e kei cy. -> .abu viskydji
by. cy.

Raising is not one of these four operations. Nor is arbitrary reordering.
So when it comes to gafygau, .abu gansu lenu by. galfi cy. dy. could only
yield the lujvo .abu gafygau by. cy. dy. This is not what we want to say
when we use an agentive 'change': we want by., the event causing the change,
out of the way completely. A changes B into C corresponds to .abu *gafygau
cy. dy.

But *this* 'change' *is* conveyed by using the raising particle jai:
lenu .abu co'e cu galfi by. cy. -> .abu jai galfi by. cy. fai lenu co'e;
cf. A changes B into C by doing D.

I was loath to disrupt the lujvo rules, and the recoverability of lujvo place
structures, by making an exception (not the only case of this, mind: I note
in the paper that superlatives may well need an exception). Instead, I have
-gau producing the 'wrong' place structure, and I would encourage lojbanists
to use 'jai' instead --- since 'jai' does do what is required here.

=But jai bapli does NOT necessarily agentify bapli - that is also an
=assumption that would have to go into the lujvo paper (which obviously does
=not cover the case since jai does not yet have the rafsi).  I am opposed
=to jai being automatically used as an agentifier, since the best arguyment
=for accepting it is its genericness.

As the statistics of jai usage Lojbab dug up confirmed, and contrary to what
Jorge supposed, virtually all usage of jai to date (mine :) ), is *not*
agentive, but extracts other roles from abstractions. But I have no problem
with that kind of vagueness being legislated into a lujvo: jai zei broda
means precisely what jai broda means --- no more, no less: it would *usually*
be an agentifier in jai bapli, that would in fact be the default presumption,
but, as is often the case with such presuppositions, it can be cancelled by
the right contextual factors. For instance, jai bapli could equally as well
extract an instrument. jai zei se zei bapli, of course, would have
nothing to do with being an agentifier, rather tending to extract topics/
goals.

Such ambiguity doesn't gel with existing lujvo policy (that each lujvo should
have a unique, unambiguous meaning), but I find pursuing such a policy for
jai lujvo impractical. (I also do so for SE + lujvo, although the converse
has been argued.)

=jai bapli merely takes SOME sumti out of the x1 place of bapli and raises it,
=or am I misremembering the intent?  Pragmatics must determine which sumti,
=and lujvo-making hard-codes the pragmatics into the dictionary.

Hm. I see that this is the real bone of contention, then. I don't think it
should, for rafsi such as SE and JAI. There can be no algorithm or method
to such hard-coding, unlike with brivla + brivla lujvo: it'd be pure
convention. I really don't see why. But I know this isn't as obvious to
Lojbab, so I dunno, maybe we shouldn't get a jai rafsi, if the string attached
to it is compulsory hard-coding of which role is extracted. (Though other
veljvo could do such disambiguation, surely.)

--
 @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
 Nick Nicholas. Melbourne University, Aus. nsn@speech.language.unimelb.edu.au
                                    ---
"Some of the English might say that the Irish orthography is very Irish.
Personally, I have a lot of respect for a people who can create something so
grotesque."
-- Andrew Rosta <ucleaar@UCL.AC.UK>, <9307262008.AA95951@link-1.ts.bcc.ac.uk>