<div dir="ltr">Thanks, Stephan and Woodley. &nbsp;To recap for future reference, the problem was in fact that the target-side grammar was also loading transfer rules (without specifying them as such with :task :transfer) and so in this lightweight LKB-LKB MT set up (which is not MMT, but what I have the students use as they work out transfer rules for translating to their languages), the target-side grammar was also trying to apply transfer rules to the (post-transfer) generator input.<div>

<br></div><div>The solution is to either not load the rules in the target-side grammar, or to be explicit about what they are for, as so:</div><div><br></div><div><div>(mt:read-transfer-rules&nbsp;</div><div>&nbsp;(list</div><div>
&nbsp; (lkb-pathname (parent-directory) &quot;acm.mtr&quot;))</div>
<div>&nbsp;&quot;A place to put your transfer rules&quot;</div><div>&nbsp;:filter nil :task :transfer)</div></div><div><br></div><div>Emily</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 1, 2014 at 7:09 AM, Stephan Oepen <span dir="ltr">&lt;<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">yes, exactly: the &lsquo;fixup&rsquo; mechanism in the generator, i.e. the optional<br>
transfer grammar invoked on generator inputs prior to lexical lookup,<br>
is defined to be ambiguity-free, i.e. must not contain optional rules.<br>
<br>
this step is not really intended for transfer, but rather to make minor<br>
adjustments to one generator input, resulting in one generator input<br>
that has a higher chance of success, for example making sure that<br>
all instance variables are quantified (if a grammar requires that) or<br>
that labels are linked up right between a quantifier and its entity.<br>
<br>
in case you need a full-fledged transfer step, i think that should be<br>
separated from generation, such that it can fan-out appropriately.<br>
<br>
i realize the explanation offered by woodley (and seconded by me<br>
now) seems at odds with your observation that it does not matter<br>
whether or not the rule in question is activated. &nbsp;but maybe there<br>
are other optional rules in the &lsquo;fixup&rsquo; transfer grammar?<br>
<br>
best, oe<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Mar 1, 2014 at 6:27 AM, Woodley Packard &lt;<a href="mailto:sweaglesw@sweaglesw.org">sweaglesw@sweaglesw.org</a>&gt; wrote:<br>
&gt; Hi Emily,<br>
&gt;<br>
&gt; The message means that the translation rules (acm.mtr) produce multiple<br>
&gt; possible outputs. &nbsp;This is because the pro-drop transfer rule is marked as<br>
&gt; optional (type &quot;monotonic_omtr&quot; as opposed to &quot;monotonic_mtr&quot;). &nbsp;I&#39;m not<br>
&gt; sure if that was intentional or? &nbsp;I tried translating eng2eng with ACE and<br>
&gt; got a related message (I assume you&#39;re using the LKB for translation - ACE<br>
&gt; issues the warning but proceeds with generation with just the first transfer<br>
&gt; result).<br>
&gt;<br>
&gt; In general it is legal to have multiple transfer results, but when transfer<br>
&gt; is done as part of the &quot;fixup&quot; stage, there is no opportunity for<br>
&gt; disambiguation, so the LKB and ACE both (apparently) assume there will only<br>
&gt; be one. &nbsp;If you want the ambiguity (e.g. if you want to try generating both<br>
&gt; ways), perhaps explicitly separating the transfer step from the generation<br>
&gt; step is called for.<br>
&gt;<br>
&gt; You say that the error appears whether or not the pro-drop rule is enabled<br>
&gt; as part of the grammar or not. &nbsp;That is not the case on my end (admittedly a<br>
&gt; different setup -- eng2eng instead of frr2eng, and ACE instead of LKB), so<br>
&gt; I&#39;m not sure what to suggest there.<br>
&gt;<br>
&gt; Good luck,<br>
&gt; -Woodley<br>
&gt;<br>
&gt; On Feb 28, 2014, at 7:54 PM, &quot;Emily M. Bender&quot; &lt;<a href="mailto:ebender@uw.edu">ebender@uw.edu</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m trying to get the LOGON MT set up ready for my students to work with,<br>
&gt; and I&#39;ve hit an error message that&#39;s new to me (in the message subject).<br>
&gt; This comes about when I try to translate from Frisian (frr) to English (eng)<br>
&gt; for any sentence with a pronoun in it. &nbsp;Sentences without pronouns work<br>
&gt; fine, and eng2frr works, even with pronouns.<br>
&gt;<br>
&gt; Perhaps relatedly, the pro-drop rule I&#39;ve defined (for other output<br>
&gt; languages) doesn&#39;t fire for frr inputs though it does for eng inputs, though<br>
&gt; I&#39;ve been unable to spot the difference in the (relevant portions of) the<br>
&gt; MRSs. &nbsp; (And the `input fix-up ambiguity&#39; error appears whether or not that<br>
&gt; rule is enabled as part of the grammar.)<br>
&gt;<br>
&gt; I&#39;m attaching the grammars in case anyone is curious, but what I&#39;m really<br>
&gt; looking for is any leads on what the error indicates.<br>
&gt;<br>
&gt; I suspect the difference has to do with the fact that the frr grammar was<br>
&gt; built last year, while eng was (re)built this year, so the Matrix versions<br>
&gt; are not the same. &nbsp;But I haven&#39;t yet been able to pinpoint a relevant<br>
&gt; difference.<br>
&gt;<br>
&gt; (This is all with Ubuntu+LKB 17, 64-bit version.)<br>
&gt;<br>
&gt; Thanks for any leads,<br>
&gt; Emily<br>
&gt;<br>
&gt; --<br>
&gt; Emily M. Bender<br>
&gt; Associate Professor<br>
&gt; Department of Linguistics<br>
&gt; Check out CLMS on facebook! <a href="http://www.facebook.com/uwclma" target="_blank">http://www.facebook.com/uwclma</a><br>
&gt; &lt;eng.tgz&gt;&lt;frr.tgz&gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Emily M. Bender<br>Associate Professor<br>Department of Linguistics<br>Check out CLMS on facebook! <a href="http://www.facebook.com/uwclma" target="_blank">http://www.facebook.com/uwclma</a><br>


</div>