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

[Francis Bond]

I am enjoying the discussions.

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