<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span>On Sun, Sep 27, 2020 at 3:16 PM Stephan Oepen <<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">[...]</span><br>
conceptually, i think all MRSs should be converted to EDSs, and no<br>
information that can be expressed in the EDS graph should be lost.<br>
more practically: each EP (and each ICONS) in the MRS should introduce<br>
a node into the EDS, and each semantic role whose value is associated<br>
with a node should yield an edge (additional edges should be<br>
introduced for instances of predicate modification). additional or<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span><br>
illformed information in the MRS (e.g. invalid handle constraints or<br>
roles whose value does not correspond to the label or intrinsic<br>
variable of an EP) should be ignored.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I agree with this, except the part about ICONS introducing nodes surprised me.. I thought that EDS, like DMRS, is yet to provide a treatment for ICONS. Care to explain?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span><br>
<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">[...]</span><br>
<br>
mike. why would you think any of the above might call for<br>
grammar-specific solutions? i would like to encourage pyDelphin to<br>
embrace the same robustness goals as the LKB-based converter. EDSs<br>
were originally invented for practical utility, to make it easier for<br>
downstream applications to work with ERG analyses; for that goal, any<br>
MRS that comes out of the parser should also yield an EDS, no matter<br>
its structure or contents.</blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">First, some clarifications/corrections: The EDS conversion error in PyDelphin is a bug, not expected behavior. Also, the dropped nodes for the disconnected DMRS was not completely described (sorry, Alexandre). The conversion actually creates nodes even for the disconnected EPs, but I was viewing the output of the dmrs-penman codec which is not capable of representing disconnected graphs (the same goes for eds-penman). They are present in other serialization formats.<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Regarding the grammar-specific solutions, as I understand the LKB's EDS code still maintains lists of ERG (1214?) predicates, roles, etc. for various uses, such as predicate modification. In the case of predicate modification, it and PyDelphin suture the unlinked nodes with the ARG1 role, if it was otherwise unused. I was under the impression that the LKB's converter did a bit more surgery in order to normalize some anticipated ill-formed structures. But if I was mistaken and the only other "value-added" part of conversion is the aforementioned top-selection with the other MRS-maladies ignored, then I think we share the same goal and view of robustness.<br></div></div><br>-- <br><div dir="ltr">-Michael Wayne Goodman</div></div>