[developers] LOGON transfer rules filling in variable properties
Emily M. Bender
ebender at uw.edu
Sat Mar 7 00:11:09 CET 2015
Actually, not quite working: Somehow the OUTPUT relation is ending up
without
a PRED value, even if I try to explicitly copy it over:
irrealis-neg-mtr := monotonic_omtr &
[ INPUT.RELS <! [ PRED #pred,
ARG0.E.MOOD mood & #m,
LBL #larg ] !>,
CONTEXT [ RELS <! [ PRED "neg_rel",
ARG1 #harg ] !>,
HCONS <! [ HARG #harg,
LARG #larg ] !> ],
OUTPUT [ RELS <! +copy+ & [ PRED #pred,
ARG0.E.MOOD irrealis ] !>,
HCONS <! !> ],
FLAGS.EQUAL < #m > ].
Is there something about +copy+ that makes it lose PRED information?
Emily
On Thu, Mar 5, 2015 at 12:47 PM, Emily M. Bender <ebender at uw.edu> wrote:
> Update! This does work. I just had my grammar in an inconsistent state.
>
> Thanks, Stephan and Woodley for the pointers.
>
> Emily
>
> On Thu, Mar 5, 2015 at 7:59 AM, Emily M. Bender <ebender at uw.edu> wrote:
>
>> 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
>>
>
>
>
> --
> 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/20150306/ffc97f6f/attachment.html>
More information about the developers
mailing list