<div dir="ltr">Thanks, Stephan and Woodley.  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 </div><div> (list</div><div>   (lkb-pathname (parent-directory) "acm.mtr"))</div> <div> "A place to put your transfer rules"</div><div> :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"><<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">yes, exactly: the ‘fixup’ 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.  but maybe there<br> are other optional rules in the ‘fixup’ 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 <<a href="mailto:sweaglesw@sweaglesw.org">sweaglesw@sweaglesw.org</a>> wrote:<br> > Hi Emily,<br> ><br> > The message means that the translation rules (acm.mtr) produce multiple<br> > possible outputs.  This is because the pro-drop transfer rule is marked as<br> > optional (type "monotonic_omtr" as opposed to "monotonic_mtr").  I'm not<br> > sure if that was intentional or?  I tried translating eng2eng with ACE and<br> > got a related message (I assume you're using the LKB for translation - ACE<br> > issues the warning but proceeds with generation with just the first transfer<br> > result).<br> ><br> > In general it is legal to have multiple transfer results, but when transfer<br> > is done as part of the "fixup" stage, there is no opportunity for<br> > disambiguation, so the LKB and ACE both (apparently) assume there will only<br> > be one.  If you want the ambiguity (e.g. if you want to try generating both<br> > ways), perhaps explicitly separating the transfer step from the generation<br> > step is called for.<br> ><br> > You say that the error appears whether or not the pro-drop rule is enabled<br> > as part of the grammar or not.  That is not the case on my end (admittedly a<br> > different setup -- eng2eng instead of frr2eng, and ACE instead of LKB), so<br> > I'm not sure what to suggest there.<br> ><br> > Good luck,<br> > -Woodley<br> ><br> > On Feb 28, 2014, at 7:54 PM, "Emily M. Bender" <<a href="mailto:ebender@uw.edu">ebender@uw.edu</a>> wrote:<br> ><br> > Hi,<br> ><br> > I'm trying to get the LOGON MT set up ready for my students to work with,<br> > and I've hit an error message that's new to me (in the message subject).<br> > This comes about when I try to translate from Frisian (frr) to English (eng)<br> > for any sentence with a pronoun in it.  Sentences without pronouns work<br> > fine, and eng2frr works, even with pronouns.<br> ><br> > Perhaps relatedly, the pro-drop rule I've defined (for other output<br> > languages) doesn't fire for frr inputs though it does for eng inputs, though<br> > I've been unable to spot the difference in the (relevant portions of) the<br> > MRSs.   (And the `input fix-up ambiguity' error appears whether or not that<br> > rule is enabled as part of the grammar.)<br> ><br> > I'm attaching the grammars in case anyone is curious, but what I'm really<br> > looking for is any leads on what the error indicates.<br> ><br> > I suspect the difference has to do with the fact that the frr grammar was<br> > built last year, while eng was (re)built this year, so the Matrix versions<br> > are not the same.  But I haven't yet been able to pinpoint a relevant<br> > difference.<br> ><br> > (This is all with Ubuntu+LKB 17, 64-bit version.)<br> ><br> > Thanks for any leads,<br> > Emily<br> ><br> > --<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> > <eng.tgz><frr.tgz><br> ><br> ><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>