<div dir="ltr"><div>I have some updates below. I don&#39;t expect a reply while Stephan&#39;s on vacation, but I want to send this while it&#39;s fresh in my mind.<br></div><div><br></div><div>I can answer the question about the use of neg. While for &quot;Not all dogs bark&quot; the meaning of &quot;not all&quot; is denoted with _not_x_deg and _all_q, for &quot;Not many dogs bark&quot; the meaning of &quot;not many&quot; 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&#39;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&#39;m not inclined to make my output harmonious; the MRS is much better in the trunk version of the ERG). I&#39;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&#39;t interviewing programmers, and Browne wasn&#39;t either.</div><div>(795) Browne merely doesn&#39;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&#39;t disprefer it as the representative EP of the conjunction because it doesn&#39;t also take neg as a non-scopal argument (the &quot;heuristic&quot; method in Slacker Semantics, and something similar is done with EDS I think). However, it&#39;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 &quot;wasn&#39;t either&quot;).</div><div><br></div><div>I&#39;m somewhat optimistic that I can resolve the differences between the LKB&#39;s and my EDS-conversion routines without resorting to grammar-specific information. I&#39;m still working with EDS produced from the 1214 ERG, so I&#39;ll need to get updated versions to make sure I&#39;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">&lt;<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>&gt;</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&#39;ll look forward to further discussion when you&#39;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">&lt;<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>&gt;</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 &lt;<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>&gt; wrote:<br>
&gt; Hi developers (but mostly Stephan and Dan),<br>
&gt;<br>
&gt; I&#39;m turning my attention briefly from TDL to making the MRS -&gt; EDS<br>
&gt; conversion in PyDelphin more harmonious with the LKB, and the first order of<br>
&gt; business is implementing &quot;predicate modification&quot;.<br>
&gt;<br>
&gt; I&#39;d like to only use grammar-agnostic graph properties to find the<br>
&gt; &quot;representative nodes&quot; of EP conjunctions, as I do with MRS -&gt; DMRS<br>
&gt; conversion, but the LKB currently does a regex match on the predicates of<br>
&gt; EPs in a conjunction, something like &quot;if the predicate matches<br>
&gt; /_x_deg$|^neg$|^_quite_x$/ and it&#39;s ARG1 is not currently assigned, set its<br>
&gt; ARG1 to point to another EP in the conjunction, with some other heuristics<br>
&gt; at work to select that other EP. (Aside: I think this ERG-specific regex<br>
&gt; pattern is now grammar-defined instead of being baked into the LKB, but<br>
&gt; currently I only see lkb/eds.lsp in the LOGON version of the ERG---not the<br>
&gt; trunk version) The _x_deg$ subpattern handles, e.g., &quot;nearly all&quot;, &quot;not<br>
&gt; all&quot;, etc., but I was having trouble finding a construction where the neg$<br>
&gt; subpattern selected a predicate modifier (any ideas?).<br>
&gt;<br>
&gt; My main concern, however, is with the _quite_x$ subpattern. It seems to work<br>
&gt; well enough with &quot;quite a few dogs bark.&quot; and &quot;quite many dogs bark.&quot; (and<br>
&gt; also &quot;quite all dogs bark&quot; and &quot;quite dogs bark&quot;, but my grammaticality<br>
&gt; judgments differ with the ERG&#39;s here). &quot;Not quite all dogs bark&quot; uses<br>
&gt; _not+quite_x, which doesn&#39;t match any subpattern and thus is disconnected in<br>
&gt; EDS. The strangest one is &quot;quite nearly all dogs barked&quot;, where in the EDS<br>
&gt; _quite_x and _nearly_x_deg select each other, cyclically, as their ARG1s<br>
&gt; (the MRS for this is as one would expect).<br>
&gt;<br>
&gt; My guess is that the *eds-predicate-modifiers* pattern is out of sync and/or<br>
&gt; insufficient with the current ERG. There are bigger issues here, such as our<br>
&gt; ever-unsatisfying treatment of quantifier modification, but right now I&#39;m<br>
&gt; just trying to figure out a good way to do EDS conversion.<br>
&gt;<br>
&gt; A request, though: if we&#39;re not going to allow quantifiers to be selected as<br>
&gt; the ARG1 of degree modifiers in MRS, can we use a different role (e.g., MOD)<br>
&gt; in EDS? That would make back-conversion simpler, I think.<br>
&gt;<br>
&gt; --<br>
&gt; 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>