[developers] ICONS and generation

Ann Copestake aac10 at cam.ac.uk
Fri Feb 5 21:11:18 CET 2016


Thanks!  I think the subsumption notion for the RELS is problematic in 
fact, but don't want to open that particular can of worms.  But wrt 
ICONS - I can think of two notions of subsumption which might be in play 
here.  One is a sort of syntactic notion - we could conceptualise the 
ICONS as a partially specified bag/multiset of icons elements - sorry, I 
don't know the proper terminology but basically {e1, e2 ...}.  Then what 
looks like an empty ICONs is actually an entirely unspecified bag { ... 
}.  But this raises the possibility that we might also allow for a 
really empty ICONS {}. The other notion is in terms of the 
interpretation of ICONS elements, which would be that the `normal' 
sentence was actually completely underspecified for its information 
structure - I can see that being plausible if the point is that a spoken 
sentence would have stress or whatever.  In that case, representing the 
ICONS as { ... } would seem right.  But - even if this is the case, I'm 
not sure that's a valid way of thinking about this for text (as opposed 
to incompletely transcribed speech).

All best,

Ann


On 05/02/2016 16:42, Woodley Packard 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
>>
>>
>>



More information about the developers mailing list