Received: from mail-wi0-f189.google.com ([209.85.212.189]:33380) by stodi.digitalkingdom.org with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1Ybkoz-0003ka-Dw; Sat, 28 Mar 2015 00:06:23 -0700 Received: by wiwh11 with SMTP id h11sf14568340wiw.0; Sat, 28 Mar 2015 00:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:sender:list-subscribe:list-unsubscribe; bh=/HRIMRLuqijJ9isc3Pm6myw7jRM1x4ju3ekijjWp3AE=; b=Ln8fFLEAalf38nJ8HUGk//Vi3jYrxk494PhSVac7Nip35ZRzHt3nUf14LasOgbQaYo dx/IpeHlmRQmlb9bC+8qvc9e4FzmGaSNhQf2eSVDWvrKDGBWue1U3Y6hHz0jkgf1KZ+J +vczhJ5KbqKF9JVoMYVyax1I0TgKm63MYtD7tBgIyRpw6eNfSIIBz3wip2dobeYNW4xk OOwqXjgiJTvQRHhFmydj9zRubqY0TArDDhdrM342vBRPl84UelGKSyFgXDwkoEV4NF9Q hK6DwjyYdwq7FR3P2GVawzEEgcZsF5drhY15QzvdH3urlAUzxUHDgu4mGIz7PfE8veCR tLqg== X-Received: by 10.152.19.134 with SMTP id f6mr361755lae.8.1427526370267; Sat, 28 Mar 2015 00:06:10 -0700 (PDT) X-BeenThere: bpfk-list@googlegroups.com Received: by 10.152.203.228 with SMTP id kt4ls467916lac.81.gmail; Sat, 28 Mar 2015 00:06:09 -0700 (PDT) X-Received: by 10.112.198.34 with SMTP id iz2mr5668737lbc.22.1427526369528; Sat, 28 Mar 2015 00:06:09 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com. [2a00:1450:400c:c05::22e]) by gmr-mx.google.com with ESMTPS id p4si273952wiz.0.2015.03.28.00.06.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2015 00:06:09 -0700 (PDT) Received-SPF: pass (google.com: domain of gleki.is.my.name@gmail.com designates 2a00:1450:400c:c05::22e as permitted sender) client-ip=2a00:1450:400c:c05::22e; Received: by mail-wi0-x22e.google.com with SMTP id g7so48826024wib.1 for ; Sat, 28 Mar 2015 00:06:09 -0700 (PDT) X-Received: by 10.194.83.134 with SMTP id q6mr41964376wjy.35.1427526369316; Sat, 28 Mar 2015 00:06:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.240.197 with HTTP; Sat, 28 Mar 2015 00:05:49 -0700 (PDT) In-Reply-To: References: From: Gleki Arxokuna Date: Sat, 28 Mar 2015 10:05:49 +0300 Message-ID: Subject: Re: [bpfk] Improvements to fragments in ilmentufa parser To: bpfk-list@googlegroups.com Content-Type: multipart/alternative; boundary=047d7bea40b8269946051253e263 X-Original-Sender: gleki.is.my.name@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of gleki.is.my.name@gmail.com designates 2a00:1450:400c:c05::22e as permitted sender) smtp.mail=gleki.is.my.name@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: bpfk-list@googlegroups.com Precedence: list Mailing-list: list bpfk-list@googlegroups.com; contact bpfk-list+owners@googlegroups.com List-ID: X-Google-Group-Id: 972099695765 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.7 (-) X-Spam_score: -1.7 X-Spam_score_int: -16 X-Spam_bar: - Content-Length: 12589 --047d7bea40b8269946051253e263 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-03-28 1:21 GMT+03:00 Jorge Llamb=C3=ADas : > >> However, selpa'i's examples don't work here. >> >> Should {noi mo} a). be restored into {noi mo cu co'e} >> > > I missed the part where "noi mo cu co'e" became grammatical. > It has two possible explanations: a). It means {zo'e noi mo cu co'e} b). It is continues by one speaker a sumti said by another speaker > >> implying {fa xi xo'e zo'e noi mo cu co'e} or b). should it instead be >> considered a continuation of the previous clause said by another speaker >> like with selpa'i's example with {be ma}? >> > > I would have said to "zo'e noi mo cu co'e" > > Both solutions seem reasonable. Maybe take option b). and treat a >> discourse split between several people as one sentence with special FUhE= .. >> FUhO markers? >> >> mi viska lo pendo FUhE [B asks] be ma [FUhO] >> mi viska lo pendo FUhE [B asks] noi mo [FUhO] >> >> A: - I see a friend. >> B: - Of whom? >> >> A: - I see a friend. >> B: - Who does what? >> >> This would reformulate fragments as parts of discourse so that we can >> remove them from the grammar. Of course, this would require somehow >> preparing existing texts by marking them with those FUhE ... FUhO so tha= t >> we can parse them. >> > > It depends on how you define "text". Is a dialogue one text, or a > succession of texts? The usual take is that it's a succession of texts, > since otherwise a lot of lojban dialogues that seem to parse would not > parse. For example the irc logs > > I also allowed relative clauses in sumti without their heads. If fragment= s >> are removed from the grammar then similar things can be useful: >> >> sumti_4 =3D expr:(sumti_5 / *relative_clauses / *gek sumti gik sumti_4) >> {return _node("sumti_4", expr);} >> > > This could be dangerous, as it makes "ta prenu poi do sisku" grammatical, > but not with the expected meaning. > I don't know what is the expected meaning here. It can be restored to {ta prenu zo'e poi do sisku ke'a} or instead to something like {fasnu fa lo nu ta prenu poi do sisku ke'a} or instead as {lo ta prenu poi do sisku ke'a cu co'e}. > Also things lika {da poi prenu ku'o noi melbi". > How is this supposed to parse according to you? I can see it again either as restoring {zo'e} or {fasnu fa lo nu} or as {lo da poi prenu ku'o noi ke'a melbi cu co'e}. > >> This results in {fa noi pendo mi cu melbi} (in fact it may even make {be= } >> useless except when used stylistically). >> > > I think it's safer to require a "lo" for bare relative clauses: "lo noi > pendo cu melbi" (this was also discussed as a good alternative to "poi'i" > in many cases). > This is related to split sumti like {fa lo gerku fa noi pendo mi cu bajra} where instead of {fa lo gerku} you have {fa zo'e}. As for you suggestion it's a continuation of the official {lo noi pendo ja'a melbi cu co'e} so it requires separate commits (do you have ideas where to patch the peg, btw?) The main problem for me now is that COhE that I showed earlier is not a true bridi_tail_t1. If you make bridi_tail_t1 elidible then it won't show up in the output. However, in camxes.js COhE does return a "COhE", not a node: GOhA_elidible =3D expr:(GOhA_clause?) {return (expr =3D=3D "") ? ["COhE"] = : _node("COhE", expr);} I could copy the whole bridi_tail_t1 with all (!) dependent strings like bridi_tail_t2 etc. only in order to inject a COhE_elidible instead of "selbri" in bridi_tail_3. However, we should be fighting copy pasting, shouldn't we? I'd also like to show ZOhE in x1 of {i broda mi} since we assume that if a selbri has x2 it must have x1. Again the same question applies: how to restore it without copying the whole "terms" part of the grammar? --=20 You received this message because you are subscribed to the Google Groups "= BPFK" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bpfk-list+unsubscribe@googlegroups.com. To post to this group, send email to bpfk-list@googlegroups.com. Visit this group at http://groups.google.com/group/bpfk-list. For more options, visit https://groups.google.com/d/optout. --047d7bea40b8269946051253e263 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-03-28 1:21 GMT+03:00 Jorge Llamb=C3=ADas <jjllambias@gmail.com= >:

How= ever, selpa'i's examples don't work here.

<= div>Should {noi mo} a). be restored into {noi mo cu co'e}
<= /div>

I missed the part where = "noi mo cu co'e" became grammatical.
<= /blockquote>

It has two possible explanations:
a). It means {zo'e noi mo cu co'e}=C2=A0
b). It is conti= nues by one speaker a sumti said by another speaker

=C2=A0
implying {fa = xi xo'e zo'e noi mo cu co'e} or b). should it instead be consid= ered a continuation of the previous clause said by another speaker like wit= h selpa'i's example with {be ma}?

I would have said to "zo'e noi mo cu= co'e"=C2=A0

Both solutions seem reasonable. Maybe take option b). and treat a discour= se split between several people as one sentence with special FUhE .. FUhO m= arkers?

mi viska lo pendo FUhE [B asks] be ma [FUh= O]
mi viska lo pendo FUhE [B asks] noi mo [FUhO]
A: - I see a friend.
B: - Of whom?

A: - I see a friend.
B: - Who does what?

This would reformulate fragments as parts of discourse so that we = can remove them from the grammar. Of course, this would require somehow pre= paring existing texts by marking them with those FUhE ... FUhO so that we c= an parse them.

It depends on how you define "text". Is a dialogue one text, o= r a succession of texts? The usual take is that it's a succession of te= xts, since otherwise a lot of lojban dialogues that seem to parse would not= parse. For example the irc logs=C2=A0

I also allowed relative clauses in sumti without their h= eads. If fragments are removed from the grammar then similar things can be = useful:

sumti_4 =3D expr:(sumti_5 / relati= ve_clauses / gek sumti gik sumti_4) {return _node("sumti_4", = expr);}

This could be dangerous, as it makes "ta prenu poi do sisku" gr= ammatical, but not with the expected meaning.

I don't know what is the expected meaning he= re. It can be restored to {ta prenu zo'e poi do sisku ke'a} or inst= ead to something like {fasnu fa lo nu ta prenu poi do sisku ke'a} or in= stead as {lo ta prenu poi do sisku ke'a cu co'e}.
=C2=A0<= /div>
Also things lika {da poi prenu ku'o noi melbi&q= uot;.

How is this s= upposed to parse according to you? I can see it again either as restoring {= zo'e} or {fasnu fa lo nu} or as {lo da poi prenu ku'o noi ke'a = melbi cu co'e}.

<= div class=3D"gmail_extra">
= =C2=A0
This results in {fa noi pendo mi cu melbi} (i= n fact it may even make {be} useless except when used stylistically).
=

I think it's = safer to require a "lo" for bare relative clauses: "lo noi p= endo cu melbi" (this was also discussed as a good alternative to "= ;poi'i" in many cases).
This is related to split sumti like {fa lo gerku fa noi pendo mi cu bajr= a} where instead of {fa lo gerku} you have {fa zo'e}.

As for you suggestion it's a continuation of the official {lo n= oi pendo ja'a melbi cu co'e} so it requires separate commits (do yo= u have ideas where to patch the peg, btw?)

The mai= n problem for me now is that COhE that I showed earlier is not a true bridi= _tail_t1. If you make bridi_tail_t1 elidible then it won't show up in t= he output. However, in camxes.js COhE does return a "COhE", not a= node:
GOhA_elidible =3D expr:(GOhA_clause?) {return (expr = =3D=3D "") ? ["COhE"] =C2=A0 : _node("COhE", = expr);}

I could copy the whole=C2=A0bridi_ta= il_t1 with all (!) dependent strings like=C2=A0bridi_tail_t2 etc. only in o= rder to inject a COhE_elidible instead of "selbri" in=C2=A0bridi_= tail_3. However, we should be fighting copy pasting, shouldn't we?

I'd also like to show ZOhE in x1 of {i broda mi} s= ince we assume that if a selbri has x2 it must have x1. Again the same ques= tion applies: how to restore it without copying the whole "terms"= part of the grammar?

--
You received this message because you are subscribed to the Google Groups &= quot;BPFK" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bpfk-list= +unsubscribe@googlegroups.com.
To post to this group, send email to bpfk-list@googlegroups.com.
Visit this group at ht= tp://groups.google.com/group/bpfk-list.
For more options, visit http= s://groups.google.com/d/optout.
--047d7bea40b8269946051253e263--