[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bpfk] BPFK work
On Mon, Oct 11, 2010 at 6:04 AM, Daniel Brockman <daniel@brockman.se> wrote:
> I consider myself a pretty pedantic {i}-user, but even I
> only start with {i} if the first thing I'm saying is a bridi.
I'm still trying to figure out where the idea that starting your part
of the conversation without an ".i" is somehow less than perfect
Lojban. Does L4B teach something like that? Where did that idea come
from? Certainly not from CLL or the old lessons. Let's check L4B. For
example:
http://www.tlg.uci.edu/~opoudjis/lojbanbrochure/lessons/less3questions.html
<<
There are two ways to answer these questions. Lojban, like some other
languages, does not have words that mean 'yes' or 'no'. One way to
answer "yes" is to repeat the selbri e.g.
- xu do nelci la bil.
- nelci
>>
No, apparently it's not from L4B. So where does this notion that
conversations are single parsable units rather than exchange of
parsable units come from?
> I don't start with {i} if the first thing I'm saying is, e.g., a UI.
> When I start with a UI, it sort of attaches to my whole text.
> It definitely does not attach to the end of some other text.
An initial UI doesn't syntactically attach to anything, because
there's nothing to its left for it to attach to. What its "object" is
(when it requires one) depends on the context. In some cases its
object is what has been said before. I don't think the object is very
often the whole following text when it gets separated by an ".i".
> So I agree with xorxes: we cannot assume a single text.
> It simply wouldn't work.
And it's not just me that says it, it's the old lessons, CLL and L4B.
Which official or even non-official document says or even suggests
that conversations have to be treated as single chunks of input for
the parser?
> (On the other hand, I think everything that is allowed at
> the beginning of a text should be allowed after {i}:
>
> A: ie pei ui pei broda
> B: ja'ai i nai
>
> And so on. I think xorxes would agree.)
Yes, I would agree with that. In fact I think NAI should be merged
with CAI, and CMEVLA should be merged with BRIVLA, and those two, NAI
and CMEVLA, are the main two odd ones that are allowed at the
beginning of text but not after I.
> When I start with a bare sumti, it can mean anything involving
> that sumti, including that I'm continuing someone's sentence.
In many cases it's an answer to a "ma" question. Continuing someone
else's sentence I would say is rare, but even in that case it can be
seen as simply making that person's sentence your own and expanding
it, so:
A: mi klama lo zarci ...
B: lo zdani
where B means "(co'e) lo zdani", and from the context it has to be
figured out that that stands for "(do klama lo zarci) lo zdani. So
there's no problem in treating B's text as their own text there.
More problematic is a case when A's sentence is not just incomplete,
but also ungrammatical by itself, so:
A: mi klama lo ...
B: zarci
Only in such cases would I really assume that B is helpfully
completing A's text.
> I still think the explicit marker cmavo would be useful.
Could be, so that would become:
A: mi klama lo ...
B: di'ai zarci
That in fact would reinforce the idea that unless it is marked
otherwise, B's text is their own, not (partly) someone else's. And in
that case the text to feed to the parser is "mi klama lo zarci", with
"di'ai" removed. This is the "twins completing each other's sentences"
kind of situation. But it shouldn't be the default.
> I'm not sure how to express explicit non-continuation, though.
> Maybe the explicit marker has a *required* NAI following it?
Or it could be a different word, say "ni'oi". But it would really be
redundant in most cases.
mu'o mi'e xorxes
--
You received this message because you are subscribed to the Google Groups "BPFK" group.
To post to this group, send email to bpfk-list@googlegroups.com.
To unsubscribe from this group, send email to bpfk-list+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bpfk-list?hl=en.