[developers] "Quite" problematic: MRS -> EDS conversion

Michael Wayne Goodman goodmami at uw.edu
Sat Jul 21 07:49:24 CEST 2018


On Fri, Jul 20, 2018 at 6:28 PM, Francis Bond <bond at ieee.org> wrote:

> I am enjoying the discussions.
>

Great! Here's some more :)

tl;dr: including scopal arguments when selecting representative EPs helps a
lot.

longer version:

I got rid of all interesting differences between PyDelphin-produced and
LKB-produced EDSs without resorting to grammar-specific information. That
is, I perform near-equivalent "predicate modification" without matching
predicate names to a regex, and near-equivalent representative node
selection without blacklisting predicate names or using specific TENSE
properties.

Based on my observation in the previous message, I changed how I select
candidate representative EPs for EP conjunctions. Before, candidates could
not select as arguments EPs within its EP conjunction (those that share its
label), but now they also cannot select EPs that are scopal arguments of
EPs in its EP conjunction. This solves the problem with (687) and (795)
before, and it worked so well that I think I'll use it for DMRS, too. I
then checked the LKB code and Stephan had in fact already reached the same
conclusion and implemented a similar solution based on our discussions 2
years ago. I guess I'm on the right track :)

I then started removing various metrics I was using to rank the
representativeness of EPs. E.g., the in-degree (number of times an EP is
the argument of other EPs sharing its label) didn't seem so useful in
practice. What I'm left with is: prefer quantifiers or quantified things
and disprefer abstract predicates. After simplifying the ranking, I had one
new diff from the CSLI testsuite:

(974) It was in January that Browne was hired.

In the ERG 1214, the _be_v_itcleft predicate selects _in_p_temp ("in
January") as its ARG1 and a the label of 4 different predicates as its
ARG2. The 4 include _in_p_temp and _hire_v_1. PyDelphin is choosing the
former and the LKB chooses the latter as the representative EPs. Before,
the in-degree was causing _hire_v_1 to be preferred (because the parg_d
introduced by the passive construction happened to tip the scales). The LKB
prefers it because it has [ TENSE untensed ]. Maybe I'll need to look at
TENSE properties after all... If I do, I might be able to drop the
"abstract predicate" criterion, which seems to overlap with [ TENSE
untensed ]. But also, the MRS for this sentence in the trunk version of the
ERG is very different; there's no _be_v_itcleft or parg_d as they have been
supplanted by ICONS.

Besides (974), there are 3 diffs in the Hike testsuite where the
LKB-produced EDSs are fragmented but mine are not. E.g.:

(611) Come along to this windswept outpost in the west.

In the ERG 1214 MRS, _to_p shares a label with _come_v_along but does not
select it as its ARG1. PyDelphin links them up but the LKB does not as
_to_p does not match the regex pattern for predicate modifiers (and FWIW
this isn't an instance of predicate modification).

Everything else is in harmony with the LKB.

If anyone has read this far, I have a question: both the ERG and Jacy have
a [ TENSE untensed ] property, but is this a more widespread convention?
I'm reluctant to rely on it because I want to avoid parametrizing my
semantic conversion functions for grammar-specific values.



> On Sat, Jul 21, 2018 at 4:37 AM, Michael Wayne Goodman <goodmami at uw.edu>
> wrote:
> > I have some updates below. I don't expect a reply while Stephan's on
> > vacation, but I want to send this while it's fresh in my mind.
> >
> > I can answer the question about the use of neg. While for "Not all dogs
> > bark" the meaning of "not all" is denoted with _not_x_deg and _all_q, for
> > "Not many dogs bark" the meaning of "not many" is denoted with udef_q,
> neg,
> > and much-many_a (with neg and udef_q sharing a label). This is apparently
> > the pattern the regex was targeting.
> >
> > I've also reduced the number of diffs on the csli testsuite from ~15 to
> 3,
> > and at least 1 of the 3 is from an ill-formed MRS (for which I'm not
> > inclined to make my output harmonious; the MRS is much better in the
> trunk
> > version of the ERG). I'm still not using any grammar-specific
> information,
> > but a fix for the other 2 of 3 diffs remains somewhat elusive. The
> sentences
> > for these 2 are:
> >
> > (687) Abrams wasn't interviewing programmers, and Browne wasn't either.
> > (795) Browne merely doesn't work.
> >
> > For (795), I (incorrectly) select _mere_a_1 as the representative EP
> instead
> > of neg; _mere_a_1 shares a label with neg, but I don't disprefer it as
> the
> > representative EP of the conjunction because it doesn't also take neg as
> a
> > non-scopal argument (the "heuristic" method in Slacker Semantics, and
> > something similar is done with EDS I think). However, it's non-scopal
> > argument is within the scopal argument of neg, so maybe I just need to
> look
> > a little deeper in the scope tree to resolve these.
> >
> > (687) has the same pattern as (795) (involving the _either_a_also, neg,
> and
> > ellipsis_ref EPs of "wasn't either").
> >
> > I'm somewhat optimistic that I can resolve the differences between the
> LKB's
> > and my EDS-conversion routines without resorting to grammar-specific
> > information. I'm still working with EDS produced from the 1214 ERG, so
> I'll
> > need to get updated versions to make sure I'm not overfitting to those
> > representations.
> >
> > (I hope these discussions of semantic representations are useful or
> > interesting to others; if not I can move it off-list)
> >
> > On Mon, Jul 16, 2018 at 3:29 PM, Michael Wayne Goodman <goodmami at uw.edu>
> > wrote:
> >>
> >> Thanks for replying!
> >>
> >> I'll look forward to further discussion when you're back from vacation.
> >>
> >> I forgot to add that my tests were using the ERG online demonstrator,
> >> which is running the 1214 version. I have not compared the outputs with
> a
> >> more recent version of the ERG.
> >>
> >> On Mon, Jul 16, 2018 at 2:53 PM, Stephan Oepen <oe at ifi.uio.no> wrote:
> >>>
> >>> hi mike,
> >>>
> >>> i am glad to hear that you are working to fully implement conversion
> >>> to EDS in PyDelphin and make results (more) LKB-compliant.  from our
> >>> earlier round of comparing across EDS code bases, i believe the EDSs
> >>> produced by the ERG on-line demonstrator should in most cases be a
> >>> good target representation.
> >>>
> >>> i am still on vacation for another good week but hope to return to
> >>> this thread in early august.  for the time being, you are certainly
> >>> right that the EDS settings in the ERG trunk have yet to be updated
> >>> for the forthcoming release (so far, i still mostly work with the
> >>> current release version, i.e. 1214).  also, i cannot immediately
> >>> recall why /^neg$/ is on the list of candidate predicate modifiers,
> >>> and probably /^_quite_x$/ should be generalized to not be anchored
> >>> string-initially.
> >>>
> >>> in general, i recall thinking back then (around 2012, i believe) that
> >>> i should put more effort into compiling a fuller list of candidate
> >>> modifiers; i also was wondering whether to provide a parallel
> >>> mechanism to allow constraining the targets of predicate modification,
> >>> e.g. limit this facility (in the ERG) to quantifiers.  your double
> >>> modification example might well provide motivation to actually
> >>> implement such a constraint ...
> >>>
> >>> more generally, i believe there are still interesting corner-cases to
> >>> be discussed in selecting the representative predication in some
> >>> configurations that involve logical conjunction (label sharing);
> >>> please see towards the end of the following page:
> >>>
> >>> http://moin.delph-in.net/EdsConversion
> >>>
> >>> if you are game, i would be happy to go back to our exercise of
> >>> systematically comparing EDS conversion results across code bases this
> >>> fall :-).  maybe we can even get bec engaged for another round?
> >>>
> >>> best wishes, oe
> >>>
> >>>
> >>> On Sun, Jul 15, 2018 at 7:24 PM, Michael Wayne Goodman <
> goodmami at uw.edu>
> >>> wrote:
> >>> > Hi developers (but mostly Stephan and Dan),
> >>> >
> >>> > I'm turning my attention briefly from TDL to making the MRS -> EDS
> >>> > conversion in PyDelphin more harmonious with the LKB, and the first
> >>> > order of
> >>> > business is implementing "predicate modification".
> >>> >
> >>> > I'd like to only use grammar-agnostic graph properties to find the
> >>> > "representative nodes" of EP conjunctions, as I do with MRS -> DMRS
> >>> > conversion, but the LKB currently does a regex match on the
> predicates
> >>> > of
> >>> > EPs in a conjunction, something like "if the predicate matches
> >>> > /_x_deg$|^neg$|^_quite_x$/ and it's ARG1 is not currently assigned,
> set
> >>> > its
> >>> > ARG1 to point to another EP in the conjunction, with some other
> >>> > heuristics
> >>> > at work to select that other EP. (Aside: I think this ERG-specific
> >>> > regex
> >>> > pattern is now grammar-defined instead of being baked into the LKB,
> but
> >>> > currently I only see lkb/eds.lsp in the LOGON version of the
> ERG---not
> >>> > the
> >>> > trunk version) The _x_deg$ subpattern handles, e.g., "nearly all",
> "not
> >>> > all", etc., but I was having trouble finding a construction where the
> >>> > neg$
> >>> > subpattern selected a predicate modifier (any ideas?).
> >>> >
> >>> > My main concern, however, is with the _quite_x$ subpattern. It seems
> to
> >>> > work
> >>> > well enough with "quite a few dogs bark." and "quite many dogs bark."
> >>> > (and
> >>> > also "quite all dogs bark" and "quite dogs bark", but my
> grammaticality
> >>> > judgments differ with the ERG's here). "Not quite all dogs bark" uses
> >>> > _not+quite_x, which doesn't match any subpattern and thus is
> >>> > disconnected in
> >>> > EDS. The strangest one is "quite nearly all dogs barked", where in
> the
> >>> > EDS
> >>> > _quite_x and _nearly_x_deg select each other, cyclically, as their
> >>> > ARG1s
> >>> > (the MRS for this is as one would expect).
> >>> >
> >>> > My guess is that the *eds-predicate-modifiers* pattern is out of sync
> >>> > and/or
> >>> > insufficient with the current ERG. There are bigger issues here, such
> >>> > as our
> >>> > ever-unsatisfying treatment of quantifier modification, but right now
> >>> > I'm
> >>> > just trying to figure out a good way to do EDS conversion.
> >>> >
> >>> > A request, though: if we're not going to allow quantifiers to be
> >>> > selected as
> >>> > the ARG1 of degree modifiers in MRS, can we use a different role
> (e.g.,
> >>> > MOD)
> >>> > in EDS? That would make back-conversion simpler, I think.
> >>> >
> >>> > --
> >>> > Michael Wayne Goodman
> >>
> >>
> >>
> >>
> >> --
> >> Michael Wayne Goodman
> >
> >
> >
> >
> > --
> > Michael Wayne Goodman
>
>
>
> --
> Francis Bond <http://www3.ntu.edu.sg/home/fcbond/>
> Division of Linguistics and Multilingual Studies
> Nanyang Technological University
>



-- 
Michael Wayne Goodman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180720/8f02f523/attachment-0001.html>


More information about the developers mailing list