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

[Michael Wayne Goodman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180720/ce6cb57b/attachment.html>