[developers] ICONS and generation

[Stephan Oepen]

hmm, several interesting questions lurking below the surface here, i feel.
 including: (a) does the absence of something (e.g. a topicalization ICONS)
provide information, i.e. serve as a constraint (blocking topicalization),
or is the lack of specific information just underspecification?  and
(b) should the semantics of parsing an unmarked input allow realization of
the marked form(s) too?

as for (b), i would suggest ‘no’ as my preference—if in part for practical
reasons (less ambiguity in the currently most common use case for the
generator).  in other words, i would expect to change something in the
parsing result to obtain an underspecified MRS.  that modification,
ideally, should be interpretable formally as removing a piece of
information.

with TPC and PSV on messages, the grammar did not have to do anything for
the ‘anti’ variables to manifest themselves in the unmarked case: type
inference in the feature structures would always put a minimal ‘u’ variable
there.  composition could then further specify that to an actual instance
variable, when a marked construction was invoked.  making the unmarked
parsing result underspecified, in turn, meant removing the TPC role
altogether.

so, in the above we were taking advantage of the assumption that the
generator never equate distinct variables (skolem forbid).  absence of TPC
is an underspecification of [ TPC u ], but the two variants (contrary to
common belief, maybe) are not equivalent.

i recall that in an earlier version at least, sanghoun and emily postulated
ICONS relations also for the unmarked case, i.e. there always tended to be
very many of them.  this would seem functionally equivalent to how TPC and
PSV worked on messages (always present, for all clauses, in parsing
results—albeit easier to overlook and easier for the grammar to add in the
unmarked case).

i believe i once expressed skepticism about such an ICONS-rich universe on
both aesthetic and practical grounds (pertaining to grammar-internal
mechanics).  i think dan held similar reservations at the time at
least and, thus, in the current ‘trunk’ analysis in the ERG the unmarked
cases do not add anything to the semantics and effectively function as if
they were underspecified.

i am not yet ready to suggest a candidate answer for my question (a) above.
 but traditionally, we use absence of information as underspecification in
various contexts.

good night, oe


On Friday, February 5, 2016, 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
>> >
>> >
>> >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160205/f83f6b8b/attachment.html>