[developers] ICONS and generation

[Ann Copestake]

Thanks!

On 05/02/2016 21:30, Emily M. Bender wrote:
> 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.
>

OK.  should I understand you as saying that composition (as in, what we 
do in the grammars) leaves it mostly underspecified, but that discourse 
level factors make it apparent?  or that it really is underspecified?

> (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?
>
Yes, I think the ICONS {} might be a possible way of thinking about it.  
I should make it clear - I don't think there's a problem with 
constructing an implementation that produces the `right' behaviour but I 
would much prefer that the behaviour is specifiable cleanly in the 
formalism rather than as another parameter to the generator or whatever.

> 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 
> <mailto: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/8f50143a/attachment-0001.html>