[developers] LOGON transfer rules filling in variable properties
Emily M. Bender
ebender at uw.edu
Thu Mar 5 16:59:32 CET 2015
Thanks, Woodley. Indeed, I was trying to use +copy+ in a type definition.
Moving that to
an instance, the grammar now compiles, and the rules don't spin, but they
also don't seem
to apply (the output is still underspecified for mood):
irrealis-neg-mtr := monotonic_mtr &
[ INPUT.RELS <! [ ARG0.E.MOOD mood & #m,
LBL #larg ] !>,
CONTEXT [ RELS <! [ PRED "neg_rel",
ARG1 #harg ] !>,
HCONS <! [ HARG #harg,
LARG #larg ] !> ],
OUTPUT [ RELS <! +copy+ & [ ARG0.E.MOOD irrealis ] !>,
HCONS <! !> ],
FLAGS.EQUAL < #m > ].
realis-nonneg-mtr := monotonic_mtr &
[ INPUT.RELS <! [ ARG0.E.MOOD mood & #m,
LBL #larg ] !>,
FILTER [ RELS <! [ PRED "neg_rel",
ARG1 #harg ] !>,
HCONS <! [ HARG #harg,
LARG #larg ] !> ],
OUTPUT [ RELS <! +copy+ & [ ARG0.E.MOOD realis ] !>,
HCONS <! !> ],
FLAGS.EQUAL < #m > ].
On Wed, Mar 4, 2015 at 5:14 PM, Woodley Packard <sweaglesw at sweaglesw.org>
wrote:
> I don't know exactly how your setup works, but it's worth pointing out
> that (to my knowledge) +copy+ and the accompanying overrides can only
> appear in an instance definition, not a type definition. Could that
> explain the behavior you're seeing? It looks like you might be writing a
> type rather than a rule.
>
> -Woodley
>
> On Mar 4, 2015, at 4:48 PM, "Emily M. Bender" <ebender at uw.edu> wrote:
>
> When I tried this with +copy+, I end up with a grammar that doesn't load:
>
> intrans-irrealis-neg-mtr := monotonic_mtr &
> [ INPUT.RELS <! [ ARG0.E.MOOD mood & #m,
> LBL #larg ] !>,
> CONTEXT [ RELS <! [ PRED "neg_rel",
> ARG1 #harg ] !>,
> HCONS <! [ HARG #harg,
> LARG #larg ] !> ],
> OUTPUT [ RELS <! +copy+ & [ ARG0.E.MOOD irrealis ] !>,
> HCONS <! !> ],
> FLAGS.EQUAL < #m > ].
>
> Unifications specified are invalid or do not unify
> Type INTRANS-IRREALIS-NEG-MTR has an invalid constraint specification
> Error: Problems in type file
>
>
> ... I suspect that this is because I'm working with the set up where the
> transfer grammar
> is actually integrated into the source side monolingual grammar and we use
> the "Rephrase"
> option in the LKB. (Because that's how I still have the students do it
> for their Lab 9 ...
> I then pull out the transfer rules into separate transfer grammars for
> the MMT demo.)
>
> This isn't a show-stopper though, so I think I'm going to leave it for now.
>
> On Wed, Mar 4, 2015 at 4:43 PM, Woodley Packard <sweaglesw at sweaglesw.org>
> wrote:
>
>> What +copy+ does is part of the undocumented magic of the transfer
>> formalism... as near as I have been able to reverse engineer, it means to
>> copy everything from the corresponding input EP, and then overwrite parts
>> of it with what is explicitly stated in the OUTPUT section. In the ACE
>> implementation, it has (if I recall correctly) exactly the same effect as
>> making the output EP reentrant to an input EP (except in that case you can
>> mix and match EP orderings).
>> -Woodley
>>
>>
>> On Mar 4, 2015, at 1:35 PM, "Emily M. Bender" <ebender at uw.edu> wrote:
>>
>> Thanks, Stephan! I'd actually gotten as far as using the FLAGS.EQUAL
>> mechanism but ran into problems because I was trying to identify
>> variables across input and output. I guess whatever +copy+ does
>> is what I was missing...
>>
>> I'll give it a try,
>> Emily
>>
>> On Wed, Mar 4, 2015 at 1:27 PM, Stephan Oepen <oe at ifi.uio.no> wrote:
>>
>>> i had to look up some examples from the original LOGON Transfer Matrix
>>> (in SVN) myself, but it would seem that the FLAGS.EQUAL mechanism is
>>> supported for variable properties. thus, something in the following
>>> spirit should work (and not cycle):
>>>
>>> INPUT < [ ARG0 [ MOOD mood & #mood ] ] >,
>>> OUTPUT < +copy+ & [ ARG0 [ MOOD realis ] ] >,
>>> FLAGS.EQUALS < #mood >
>>>
>>> if, for some reason, the above refuses to cooperate, i dimly recall
>>> introducing ‘decorator’ EPs (e.g. ‘plural_noun_mark’ in the Transfer
>>> Matrix) to prevent cyclic rule applications: once the variable
>>> property is refined, one can put a mark on that variable, and
>>> somewhere towards the end of transfer all marks can be dropped ...
>>>
>>> good luck putting it all together! oe
>>>
>>>
>>> On Wed, Mar 4, 2015 at 9:43 PM, Emily M. Bender <ebender at uw.edu> wrote:
>>> > Dear all,
>>> >
>>> > I'm reaching the end of this year's Ling 567, and this time around we
>>> have
>>> > two languages (Bardi [bcj] and Lithuanian [lit]) that contrast realis
>>> and
>>> > irrealis
>>> > mood, where irrealis is required in negated sentences but also possible
>>> > elsewhere (with other uses).
>>> >
>>> > We typically use VPM to set defaults for various variable properties
>>> to keep
>>> > the range of generator outputs down in our MT set up, but can't in this
>>> > case set MOOD to realis by default, since then we don't get any output
>>> > for negated sentences.
>>> >
>>> > It seemed tempting to try to create a family of transfer rules that
>>> > specialize
>>> > MOOD on the ARG0 of negated _v_rels (i.e. whose LBL is the LARG of a
>>> qeq
>>> > whose HARG is the ARG1 of neg_rel) to [ MOOD irrealis ] and that of
>>> > _v_rels that aren't negated to [ MOOD realis ]. The trouble is, I
>>> can't
>>> > figure
>>> > out a way to write this rule that doesn't feed itself.
>>> >
>>> > Is there something I'm missing, or (perhaps more likely) is this just
>>> not an
>>> > intended use case for the transfer rules/otherwise a bad idea in some
>>> way?
>>> >
>>> > Thanks,
>>> > Emily
>>> >
>>> > --
>>> > Emily M. Bender
>>> > Professor, Department of Linguistics
>>> > Check out CLMS on facebook! http://www.facebook.com/uwclma
>>> >
>>>
>>
>>
>>
>> --
>> Emily M. Bender
>> Professor, Department of Linguistics
>> Check out CLMS on facebook! http://www.facebook.com/uwclma
>>
>>
>>
>
>
> --
> Emily M. Bender
> Professor, Department of Linguistics
> Check out CLMS on facebook! http://www.facebook.com/uwclma
>
>
>
--
Emily M. Bender
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/20150305/3d083902/attachment.html>
More information about the developers
mailing list