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

Sun Jul 22 16:46:43 CEST 2018

MRS from more recent improvements to the ERG is certainly better!

Looking at one of your other examples, I don’t understand the ellipsis predication shown below for:

*	Browne wasn’t either.

The ARG1 of the ellipsis_ref_rel being “Browne” confuses me, probably because I don’t understand ellipsis_ref_rel.

My guess is that it represents that an ellipsis occurred (e3) which leads me to expect that an ‘i’ variable, or perhaps a ‘u’ variable would be ARG1.

Any elucidation would be appreciated.

Paul

From: Michael Wayne Goodman <goodmami at uw.edu> 
Sent: Saturday, July 21, 2018 12:37 PM
To: paul at haleyai.com
Cc: Francis Bond <bond at ieee.org>; developers <developers at delph-in.net>
Subject: Re: [developers] "Quite" problematic: MRS -> EDS conversion

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 <mailto: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 <mailto:developers-bounces at emmtee.net>  <developers-bounces at emmtee.net <mailto: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 <mailto:bond at ieee.org> >
Cc: developers <developers at delph-in.net <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/20180722/3aa777a1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 42929 bytes
Desc: not available
URL: <http://lists.delph-in.net/archives/developers/attachments/20180722/3aa777a1/attachment-0001.png>