<div dir="ltr"><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>(687) Abrams wasn't interviewing programmers, and Browne wasn't either.</div><div>(795) Browne merely doesn't work.</div><div><br></div><div>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.</div><div><br></div><div>(687) has the same pattern as (795) (involving the _either_a_also, neg, and ellipsis_ref EPs of "wasn't either").</div><div><br></div><div>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.</div><div><br></div><div>(I hope these discussions of semantic representations are useful or interesting to others; if not I can move it off-list)<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 16, 2018 at 3:29 PM, Michael Wayne Goodman <span dir="ltr"><<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks for replying!</div><div><br></div><div>I'll look forward to further discussion when you're back from vacation.</div><div><br></div><div>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.<br></div><div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Jul 16, 2018 at 2:53 PM, Stephan Oepen <span dir="ltr"><<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi mike,<br>
<br>
i am glad to hear that you are working to fully implement conversion<br>
to EDS in PyDelphin and make results (more) LKB-compliant. from our<br>
earlier round of comparing across EDS code bases, i believe the EDSs<br>
produced by the ERG on-line demonstrator should in most cases be a<br>
good target representation.<br>
<br>
i am still on vacation for another good week but hope to return to<br>
this thread in early august. for the time being, you are certainly<br>
right that the EDS settings in the ERG trunk have yet to be updated<br>
for the forthcoming release (so far, i still mostly work with the<br>
current release version, i.e. 1214). also, i cannot immediately<br>
recall why /^neg$/ is on the list of candidate predicate modifiers,<br>
and probably /^_quite_x$/ should be generalized to not be anchored<br>
string-initially.<br>
<br>
in general, i recall thinking back then (around 2012, i believe) that<br>
i should put more effort into compiling a fuller list of candidate<br>
modifiers; i also was wondering whether to provide a parallel<br>
mechanism to allow constraining the targets of predicate modification,<br>
e.g. limit this facility (in the ERG) to quantifiers. your double<br>
modification example might well provide motivation to actually<br>
implement such a constraint ...<br>
<br>
more generally, i believe there are still interesting corner-cases to<br>
be discussed in selecting the representative predication in some<br>
configurations that involve logical conjunction (label sharing);<br>
please see towards the end of the following page:<br>
<br>
<a href="http://moin.delph-in.net/EdsConversion" rel="noreferrer" target="_blank">http://moin.delph-in.net/EdsCo<wbr>nversion</a><br>
<br>
if you are game, i would be happy to go back to our exercise of<br>
systematically comparing EDS conversion results across code bases this<br>
fall :-). maybe we can even get bec engaged for another round?<br>
<br>
best wishes, oe<br>
<div class="m_-4632597755019906382HOEnZb"><div class="m_-4632597755019906382h5"><br>
<br>
On Sun, Jul 15, 2018 at 7:24 PM, Michael Wayne Goodman <<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>> wrote:<br>
> Hi developers (but mostly Stephan and Dan),<br>
><br>
> I'm turning my attention briefly from TDL to making the MRS -> EDS<br>
> conversion in PyDelphin more harmonious with the LKB, and the first order of<br>
> business is implementing "predicate modification".<br>
><br>
> I'd like to only use grammar-agnostic graph properties to find the<br>
> "representative nodes" of EP conjunctions, as I do with MRS -> DMRS<br>
> conversion, but the LKB currently does a regex match on the predicates of<br>
> EPs in a conjunction, something like "if the predicate matches<br>
> /_x_deg$|^neg$|^_quite_x$/ and it's ARG1 is not currently assigned, set its<br>
> ARG1 to point to another EP in the conjunction, with some other heuristics<br>
> at work to select that other EP. (Aside: I think this ERG-specific regex<br>
> pattern is now grammar-defined instead of being baked into the LKB, but<br>
> currently I only see lkb/eds.lsp in the LOGON version of the ERG---not the<br>
> trunk version) The _x_deg$ subpattern handles, e.g., "nearly all", "not<br>
> all", etc., but I was having trouble finding a construction where the neg$<br>
> subpattern selected a predicate modifier (any ideas?).<br>
><br>
> My main concern, however, is with the _quite_x$ subpattern. It seems to work<br>
> well enough with "quite a few dogs bark." and "quite many dogs bark." (and<br>
> also "quite all dogs bark" and "quite dogs bark", but my grammaticality<br>
> judgments differ with the ERG's here). "Not quite all dogs bark" uses<br>
> _not+quite_x, which doesn't match any subpattern and thus is disconnected in<br>
> EDS. The strangest one is "quite nearly all dogs barked", where in the EDS<br>
> _quite_x and _nearly_x_deg select each other, cyclically, as their ARG1s<br>
> (the MRS for this is as one would expect).<br>
><br>
> My guess is that the *eds-predicate-modifiers* pattern is out of sync and/or<br>
> insufficient with the current ERG. There are bigger issues here, such as our<br>
> ever-unsatisfying treatment of quantifier modification, but right now I'm<br>
> just trying to figure out a good way to do EDS conversion.<br>
><br>
> A request, though: if we're not going to allow quantifiers to be selected as<br>
> the ARG1 of degree modifiers in MRS, can we use a different role (e.g., MOD)<br>
> in EDS? That would make back-conversion simpler, I think.<br>
><br>
> --<br>
> Michael Wayne Goodman<br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-4632597755019906382gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Michael Wayne Goodman</div></div></div></div></div></div>
</font></span></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Michael Wayne Goodman</div></div></div></div></div></div>
</div>