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

[Stephan Oepen]

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