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

[Michael Wayne Goodman]

Thanks, Paul,

I found the "Browne merely doesn't work" example a little surprising at
first, too, but I think it's a consequence of the composition. I think the
INDEX of the "doesn't work" subgraph is the ARG0 of _work_v_1, and the LTOP
is the label of neg (which can be seen as the MRS TOP and INDEX in "Browne
doesn't work"), and _mere_a_1 is merely using the hook values that are
available to it. In other words, "merely" is modifying the subgraph for
"doesn't work" as a whole.

At least, that's my guess, but I'd be happy if someone could offer a better
explanation.

But there are certainly some MRSs in the test set that are ill-formed or
less-than-ideal. I'm looking forward to using the new ERG :)

On Sat, Jul 21, 2018 at 8:41 AM, <paul at haleyai.com> wrote:

> I am also interested in the discussion, enjoying some of the cases your
> point out, ... and wondering if the MRS is as it should be in some cases.
>
>
>
> In “Browne merely doesn’t work”, the MRS indicates that merely modifies
> “work” rather than the negation.
>
>
>
> That strikes me as incorrect.  Am I missing something?
>
>
>
> Regards,
>
> Paul
>
>
>
> *From:* developers-bounces at emmtee.net <developers-bounces at emmtee.net> *On
> Behalf Of *Michael Wayne Goodman
> *Sent:* Saturday, July 21, 2018 1:49 AM
> *To:* Francis Bond <bond at ieee.org>
> *Cc:* developers <developers at delph-in.net>
> *Subject:* Re: [developers] "Quite" problematic: MRS -> EDS conversion
>
>
>
> 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
>



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