[developers] ICONS and generation
aac10 at cam.ac.uk
Fri Feb 5 22:31:31 CET 2016
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.
On 05/02/2016 21:01, Stephan Oepen wrote:
> 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
> 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 :-)
> > On Feb 5, 2016, at 8:03 AM, Ann Copestake <aac10 at cl.cam.ac.uk>
> > 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
> > 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
> > Ann
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers