Received-SPF: pass (google.com: domain of gleki.is.my.name@gmail.com designates 2a00:1450:400c:c05::236 as permitted sender) client-ip=2a00:1450:400c:c05::236;
MIME-Version: 1.0
From: Gleki Arxokuna <gleki.is.my.name@gmail.com>
Date: Sun, 12 Apr 2015 18:00:30 +0300
Message-ID: <CAO7bV+jD0wjsMv1tMbSn6TkLU_mJraEjBqSpNWt5vKeYA27cpA@mail.gmail.com>
Subject: [bpfk] FA-autorestoration rules
To: bpfk-list@googlegroups.com
Content-Type: multipart/alternative; boundary=f46d04447f83652590051388437d
Reply-To: bpfk-list@googlegroups.com
Precedence: list
Mailing-list: list bpfk-list@googlegroups.com; contact bpfk-list+owners@googlegroups.com
Sender: bpfk-list@googlegroups.com
X-Spam_score: -1.4
X-Spam_score_int: -13
X-Spam_bar: -
Content-Length: 7948

--f46d04447f83652590051388437d
Content-Type: text/plain; charset=UTF-8

Terminology:
*Z*A*M* - *Z*ero-marked ter*m* without a tag, i.e. bare sumti. FA prefix is
omitted and has to be restored. Fills verb valency.
*FAM* - ter*m* with an explicit *FA*-tag, i.e. prefixed with FA by the
speaker, not the analyzer. Fills verb valency.
*BAM* - ter*m* with any other tag like e.g. *BA*I. Otherwise known as
semantic preposition.

There's been a suggestion that {be ko'a} = {be fi ko'a}.
I think this is plain wrong.

The correct rule is
"Bridi head always has at least one place filled. If not it is implied.
ZAMs get places consequentially in their order". CLL states the same
using other
words <http://dag.github.io/cll/9/2/>.

What place should take this implied ZAM? Judging by how linkargs work I
propose that it is x1.

Thus
{i carvi} => {i zo'e carvi} => {i fa zo'e carvi}

Now what if we say {i carvi fa ko'a}?
There is a rule related to {go'i}. Consider the dialogue:
- la tom cu klama = Tom comes.
- la alis cu go'i = Alice comes.
I think this rule should be applied here as well.

{i carvi fa ko'a} is expanded to {i fa zo'e carvi fa ko'a}.
Since the rule with {go'i} simply replaces sumti with new ones (not
necessarily negating replaced ones) we expand it to:
{i fa zo'e carvi i carvi fa ko'a}
I used {i} here to link two resulting sentences, however, it's a special
{i} that retains all referents of the initial sentence to be expanded under
one discourse (just like {go'i} does).

Now, {i fa zo'e carvi} does pretty much nothing, so semantically we get
just {i fa ko'a carvi}.

Now let's look at linkargs.
{lo broda be ko'a cu brodi}. Here clearly, broda1 is filled with zo'e, thus
ko'a HAS TO take broda2 place as if we said {i broda ko'a} => {i zo'e broda
ko'a} => {i fa zo'e broda fe ko'a}. This happens due to consequential
applying of places to ZAMs.

This all might seem obvious, useless and maybe creating no new rules (maybe
only applying old rules to new constructs) but only until you want to delve
into trickier cases.

{lo broda be fa ko'a cu brodi}. Here we have to apply the rule taken from
{go'i}. Again broda1 is filled with zo'e, however, the next part refills it
again but now with {ko'a} so we generally result in (disregarding focus and
the order of sentences):

{zo'e noi broda cu brodi i ko'a broda} => {lo broda cu brodi i ko'a broda}.

{lo nixli be fa la alis cu melbi} = The girl Alice is pretty.

I know there've been other proposals to specially treat x2 cases but since
CLL already has either explicit instructions or hints I think it'd be nice
to limit the number of rules and not to multiply entities when there is no
need in them. Think of newcomers!

There is certainly some underformalization on what to do when FAMs and ZAMs
are used together in one sentence (once again, FAMs are tags filled with FA
*before* we analyze bridi i.e. filled usually by speakers).

I think my thoughts on bridi head and {go'i} could be applied to this
interaction as well but probably too much info now so for another time.

-- 
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 email 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.

--f46d04447f83652590051388437d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Terminology:</div><div><b>Z</b>A<b>M</b> - <b>Z</b>er=
o-marked ter<b>m</b> without a tag, i.e. bare sumti. FA prefix is omitted a=
nd has to be restored. Fills verb valency.</div><div><b>FAM</b> - ter<b>m</=
b> with an explicit <b>FA</b>-tag, i.e. prefixed with FA by the speaker, no=
t the analyzer. Fills verb valency.<br></div><div><b>BAM</b> - ter<b>m</b> =
with any other tag like e.g. <b>BA</b>I. Otherwise known as semantic prepos=
ition.<br></div><div><br>There&#39;s been a suggestion that {be ko&#39;a} =
=3D {be fi ko&#39;a}.</div><div>I think this is plain wrong.</div><div><br>=
</div><div>The correct rule is=C2=A0</div><div>&quot;Bridi head always has =
at least one place filled. If not it is implied. ZAMs get places consequent=
ially in their order&quot;. CLL states the same using <a href=3D"http://dag=
.github.io/cll/9/2/">other words</a>.</div><div><br></div><div>What place s=
hould take this implied ZAM? Judging by how linkargs work I propose that it=
 is x1.</div><div><br></div><div>Thus=C2=A0</div><div>{i carvi} =3D&gt; {i =
zo&#39;e carvi} =3D&gt; {i fa zo&#39;e carvi}<br><br>Now what if we say {i =
carvi fa ko&#39;a}?<br>There is a rule related to {go&#39;i}. Consider the =
dialogue:<br>- la tom cu klama =3D Tom comes.</div><div>- la alis cu go&#39=
;i =3D Alice comes.<br>I think this rule should be applied here as well.<br=
><br>{i carvi fa ko&#39;a} is expanded to {i fa zo&#39;e carvi fa ko&#39;a}=
.</div><div>Since the rule with {go&#39;i} simply replaces sumti with new o=
nes (not necessarily negating replaced ones) we expand it to:<br>{i fa zo&#=
39;e carvi i carvi fa ko&#39;a}<br>I used {i} here to link two resulting se=
ntences, however, it&#39;s a special {i} that retains all referents of the =
initial sentence to be expanded under one discourse (just like {go&#39;i} d=
oes).</div><div><br></div><div>Now, {i fa zo&#39;e carvi} does pretty much =
nothing, so semantically we get just {i fa ko&#39;a carvi}.<br><br>Now let&=
#39;s look at linkargs.<br>{lo broda be ko&#39;a cu brodi}. Here clearly, b=
roda1 is filled with zo&#39;e, thus ko&#39;a HAS TO take broda2 place as if=
 we said {i broda ko&#39;a} =3D&gt; {i zo&#39;e broda ko&#39;a} =3D&gt; {i =
fa zo&#39;e broda fe ko&#39;a}. This happens due to consequential applying =
of places to ZAMs.<br><br>This all might seem obvious, useless and maybe cr=
eating no new rules (maybe only applying old rules to new constructs) but o=
nly until you want to delve into trickier cases.</div><div><br>{lo broda be=
 fa ko&#39;a cu brodi}. Here we have to apply the rule taken from {go&#39;i=
}. Again broda1 is filled with zo&#39;e, however, the next part refills it =
again but now with {ko&#39;a} so we generally result in (disregarding focus=
 and the order of sentences):<br><br>{zo&#39;e noi broda cu brodi i ko&#39;=
a broda} =3D&gt; {lo broda cu brodi i ko&#39;a broda}.<br><br>{lo nixli be =
fa la alis cu melbi} =3D The girl Alice is pretty.<br><br>I know there&#39;=
ve been other proposals to specially treat x2 cases but since CLL already h=
as either explicit instructions or hints I think it&#39;d be nice to limit =
the number of rules and not to multiply entities when there is no need in t=
hem. Think of newcomers!<br><br>There is certainly some underformalization =
on what to do when FAMs and ZAMs are used together in one sentence (once ag=
ain, FAMs are tags filled with FA <b>before</b> we analyze bridi i.e. fille=
d usually by speakers).<br><br>I think my thoughts on bridi head and {go=
9;i} could be applied to this interaction as well but probably too much inf=
o now so for another time.</div></div>

<p></p>

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

--f46d04447f83652590051388437d--