[developers] ICONS and generation

[Emily M. Bender]

Not sure if this answers the question, but a couple of comments:

(a) I do think that written English is largely underspecified for
information structure.
It's part of what makes good writing good that the information structure is
made apparent
somehow.

(b) I think the "I want only the unmarked form back" case might be handled
by either
a setting which says "no ICONS beyond what as in the input" (i.e. your
ICONS { }) or
a pre-processing/generation fix-up rule that takes ICONS { ... } and
outputs something
that would be incompatible with anything but the unmarked form.  Or maybe
the
subsumption check goes the wrong way for this one?

I hope Sanghoun has something to add here!

Emily

On Fri, Feb 5, 2016 at 1:01 PM, Stephan Oepen <oe at ifi.uio.no> wrote:

> colleagues,
>
> my ideal would be a set-up where the provider of generator inputs has
> three options: (a) request topicalization (or similar), (b) disallow it, or
> (c) underspecify and get both variants.
>
> we used to have that level of control (and flexibility) in the LOGON days
> where there were still messages: in the message EPs, there were two
> optional ‘pseudo’ roles (TPC and PSV) to control topicalization or
> passivization of a specific instance variable.  effectively, when
> present, these established a binary relation between the clause and one of
> its nominal constituents.  if i recall correctly, blocking topicalization
> was accomplished by putting an otherwise unbound ‘anti’-variable into the
> TPC or PSV roles.
>
> could one imagine something similar in the ICONS realm, and if so, which
> form would it have to take?
>
> best wishes, oe
>
>
> On Friday, February 5, 2016, Woodley Packard <sweaglesw at sweaglesw.org>
> wrote:
>
>> I can confirm that under ACE, behavior is what you indicate, i.e.
>> generating from parsing the topicalized feline-canine-playtime I get just
>> the topicalized variant out, but when generating from parsing the ordinary
>> word order I get all 5 variants out.
>>
>> I believe this was designed to imitate the long-standing condition that
>> the MRS of generation results must be subsumed by the input MRS.  The
>> observed behavior seems to me to be the correct interpretation of the
>> subsumption relation with ICONS involved.  Note that an MRS with an extra
>> intersective modifier would also be subsumed, for example, but such MRS are
>> never actually generated since those modifier lexical entries never make it
>> into the chart.
>>
>> It’s certainly reasonable to ask whether (this notion of) subsumption is
>> really the right test.  I’ve met lots of folks who prefer to turn that
>> subsumption test off entirely.  I guess it’s also possible that the
>> subsumption test is right for the RELS portion of the MRS but not for the
>> ICONS, though that seems a bit odd to consider.  However, given that we
>> don’t have many ideas about truth-conditional implications of ICONS, maybe
>> not so odd.
>>
>> I don’t really have much to offer in terms of opinions about what the
>> right behavior should be.  I (believe I) just implemented what others asked
>> for a couple years ago :-)
>>
>> -Woodley
>>
>> > On Feb 5, 2016, at 8:03 AM, Ann Copestake <aac10 at cl.cam.ac.uk> wrote:
>> >
>> > I'm part way through getting ICONS support working in Lisp, testing on
>> the version of the ERG available as trunk. I have a question about
>> generation.  If I implemented the behaviour described in
>> http://moin.delph-in.net/IconsSpecs there doesn't seem to be a way of
>> specifying that I want a `normal' ordering for English.
>> >
>> > e.g., if I take the MRS resulting from
>> >
>> > that dog, the cat chased.
>> >
>> > without ICONS check, there are 5 realizations, including the `null
>> ICONS' case `The cat chased that dog.'  With an exact ICONS check, I can
>> select realizations with the same ICONS (modulo order of ICONS elements, of
>> course, in the case where there's more than one element).  But with the
>> http://moin.delph-in.net/IconsSpecs behaviour, there's no way of
>> specifying I want a `normal' order - if I don't give an ICONS, I will
>> always get the 5 realisations. In fact, as I understand it, I can always
>> end up with more icons in the realisation than in the input, as long as I
>> can match the ones in the input.
>> >
>> > So:
>> > - is the IConsSpec behaviour what is desired for the ERG (e.g., because
>> one can rely on the realisation ranking to prefer the most `normal' order)?
>> > - or does the ERG behave differently from Emily and Sanghoun's
>> grammars, such that different generator behaviour is desirable? and if so,
>> could we change things so we don't need different behaviours
>> >
>> > Ann
>> >
>> >
>> >
>>
>>
>>


-- 
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/20160205/92894a17/attachment-0001.html>