[developers] LOGON: error `input fix-up ambiguity: 2 outputs'

[Emily M. Bender]

And one last breadcrumb for posterity:

In fact, it seems that while adding :task :transfer blocks the rules from
being used as post-transfer fix-up rules, it also blocks them (in this
set-up) from being used as transfer rules.

Emily


On Sat, Mar 1, 2014 at 1:14 PM, Emily M. Bender <ebender at uw.edu> wrote:

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



-- 
Emily M. Bender
Associate Professor
Department of Linguistics
Check out CLMS on facebook! http://www.facebook.com/uwclma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20140303/df2734da/attachment.html>