[developers] ICONS and generation

[Ann Copestake]

Well, yes - as far as I can tell, Song and Bender 2012 does underspecify 
in a way that allows a very fine-grained control with ICONS in a way 
which makes sense formaly. I've just (re)skimmed the paper and haven't 
looked at the associated grammar, but I raised the question I did 
because I'm not sure whether the ERG analysis is intended to be the same 
or not.  There is a difference between having an ICONS element with an 
underspecified info-str relation and not having an ICONS element at 
all.  We might be able to get the fine-grained control using the ERG 
analysis but possibly only with a different interpretation of ICONS.

Ann

On 05/02/2016 21:01, Stephan Oepen 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 
> <javascript:_e(%7B%7D,'cvml','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
>     >
>     >
>     >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160205/ca498302/attachment.html>