[developers] Fwd: [delph-in] ICONS with ACE
sweaglesw at sweaglesw.org
Fri Nov 16 02:31:21 CET 2012
Hi Emily and other developers,
In answer to your question, what I did in ACE is fairly straightforward. To begin with, I made ICONS processing optional, enabled by the "enable-icons := yes." configuration parameter (and a couple of accompanying settings), which is off by default. When ICONS processing is on, all MRSes (extracted from feature structures, parsed from strings/files, or formatted for output) have an additional ICONS list. It follows the form of the HCONS list in just about every way, except that we expect a richer hierarchy for the constraints types.
The post-generation subsumption test generally verifies that a candidate realization's MRS contains all of the information specified on the input MRS (and possibly more). For HCONS, at least in ACE, that means ensuring that there is at least one unique realized HCONS element that is compatible with each input HCONS element. I used almost exactly the same algorithm to test ICONS compatibility -- i.e. I look for an injective mapping from the input ICONS list to the realization's ICONS list, such that (1) variable identities are compatible, (2) variable properties are subsumed, and (3) the constraint's type is subsumed. If, after satisfying all of the input ICONS elements, there are leftover realization ICONS elements, I don't currently consider that grounds for rejecting the result. This allows inputs with empty ICONS lists to still generate, for instance.
Hope that helps,
On Nov 15, 2012, at 5:10 PM, Emily M. Bender wrote:
> Dear all,
> Just following up on Sanghoun's message below, I wanted to paste in
> the specs that we had originally put together:
> The behavior we would like to see is partially documented
> in the files eng.txt and jpn.txt (in the attached tarball), which
> associate input sentences (for parsing) with the realizations
> the generator currently finds. Among those, we have marked the
> ones we would like to not see.
> In general, the idea is that for any given pair of indices, if there
> is an ICONS element in the MRS associated with a realization
> that realization is valid iff:
> --- There is no ICONS element associated with the same pair
> of indices in the input; or
> --- Any ICONS element associated with the same pair of indices
> in the input is compatible in its type with the ICONS element
> in the candidate realization.
> (I'm not sure as I type this what to do about cases where there
> are multiple ICONS elements for the same pair of indices. As far
> as information structure is concerned, we wouldn't expect to have
> more than one. Of course, if we're putting other stuff into ICONS,
> then there might be ICONS constraints of different types. All
> of the above would then be only applicable to subtypes of info-str.)
> Woodley and I had a little bit of a follow-up discussion, which
> resulted in the following conclusion:
> I see that the condition you describe could be summarized as "the
> input ICONS list and the realization's ICONS list are unifiable",
> under a reasonable extension of the term.
> Then Woodley did some magic, and ACE now treats ICONS the
> way we would like them to be treated. Woodley, can you reconstruct
> what further decisions you had to make to operationalize the
> specs above?
> ---------- Forwarded message ----------
> From: Sanghoun Song <sanghoun at uw.edu>
> Date: Fri, Nov 9, 2012 at 8:13 PM
> Subject: [delph-in] ICONS with ACE
> To: participants at delph-in.net
> Dear DELPH-IN developers,
> Last time in Sofia, we had time to discuss making our analyzers handle
> ICONS (Individual CONstraitS). If you want, you can review what we
> discussed here.
> After that, we circulated a set of desiderata based on how we are
> using ICONS in information structure. Woodley has successfully
> integrated ICONS processing into ACE (thanks, Woodley!). Using this
> version, Emily and I conducted a small experiment that tried to
> paraphrase English and Japanese sentences with reference to the given
> information structure, which worked just as expected. The paper was
> published in the proceedings of HPSG2012, which you can see here.
> I'm hoping ICONS can be more actively used in our framework for
> generation purposes, and also that other DELPH-IN parser-generators
> will integrate ICONS processing. Thanks again to Woodley for
> Sanghoun Song (PhC)
> Dept. of Linguistics, Univ. of Washington
> Emily M. Bender
> Associate Professor
> Department of Linguistics
> Check out CLMS on facebook! http://www.facebook.com/uwclma
More information about the developers