<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Am Mo., 27. Aug. 2018 um 19:47 Uhr schrieb <a href="mailto:goodman.m.w@gmail.com">goodman.m.w@gmail.com</a> &lt;<a href="mailto:goodman.m.w@gmail.com">goodman.m.w@gmail.com</a>&gt;:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Thanks, Guy, for the detailed reply and interesting examples!<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 23, 2018 at 4:56 AM Guy Emerson &lt;<a href="mailto:gete2@cam.ac.uk" target="_blank">gete2@cam.ac.uk</a>&gt; 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"><div dir="ltr"><div>(Replying here rather than on <a href="http://lists.delph-in.net/archives/developers/2018/002803.html" target="_blank">http://lists.delph-in.net/archives/developers/2018/002803.html</a>)<br></div><div><br></div><div>I would generally support this.<br></div><div><br></div><div>In the case of multiple ICONS links, I don&#39;t think it would be a good idea to put *one* of them on top of the regular link and the other on an ICONS-only link.  The first question is: is there a need for this?  (Sanghoun? Dan?)  Given that ICONS are organised in a type hierarchy, I&#39;m not sure what would need to be handled by having multiple links, rather than a larger hierarchy.  If there is a clear use case, then I would suggest putting them all on the same link, with a different separator (perhaps a comma).<br></div></div></blockquote><div> </div><div><div style="font-family:arial,helvetica,sans-serif">I cannot answer the &quot;is there a need&quot; question, but regarding the serialization issue I can agree with having all on the same link joined with some delimiter. Let&#39;s use your comma-delimited suggestion as our working proposal.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>For ICONS-only links, we may want to use default values for rargname and post.  Ann has already proposed using e.g. MOD/EQ for an HCONS-only link.  NEQ is effectively the default value for HCONS (without going into a longer discussion of scope).  On the other hand, writing MOD/NEQ/topic would seem strange, since an ICONS link is not modifying something.  So I&#39;m not sure about using MOD.  Using NEQ seems more sensible,* and would contrast with cases where there is just HCONS and ICONS -- e.g. in Sanghoun&#39;s book (<a href="http://langsci-press.org/catalog/book/111" target="_blank">http://langsci-press.org/catalog/book/111</a>), relative clauses introduce ICONS links from the verbs to the modified noun, so with &quot;I saw the dog whose ears are brown&quot;, there would be both an EQ link from &quot;brown&quot; to &quot;dog&quot;, as well as an ICONS link.  So this could be written as MOD/EQ/focus-or-topic.  But without the EQ link, I&#39;m not sure.  ???/NEQ/focus-or-topic.<br></div></div></blockquote><div style="font-family:arial,helvetica,sans-serif"></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">I agree that MOD is the wrong choice for a default role for ICONS-only links. But I dislike using NEQ as the default post-slash value. While it&#39;s ostensibly true if there&#39;s no */EQ link, it&#39;s making an unnecessary claim about scope. For these cases I would prefer leaving it empty, e.g., //focus-or-topic.</div></div></div></blockquote><div><br></div><div>I&#39;m convinced by your &quot;very furry dog&quot; example.  It seems not unreasonable that there could be an ICONS link from &quot;very&quot; to &quot;dog&quot;.<br></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"><div dir="ltr"><div class="gmail_quote"><div style="font-family:arial,helvetica,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>We also need to consider cases where an ICONS link goes in the opposite direction to a regular link (&quot;it was on Monday that it rained&quot;).  It seems to me that there are two choices -- adding the inverse ICONS to the regular link (in this case, the ARG1/EQ link from &quot;on&quot; to &quot;rain&quot;), or adding a second link in the opposite direction from the regular link.  Using inverse ICONS complicates ICONS, but using two links complicates the graph topology.<br></div></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif">I was unable to reproduce this configuration using the r26803 version of the ERG, but it should be a possible configuration. It seems that EDS/DMRS graphs with ICONS may no longer be acyclic. Regardless of how they are encoded, I wonder if we could treat ICONS more like node properties than structural links, so that we could at least pretend that the structure is still a DAG. But really, I&#39;m not sure if ICONS are &quot;structure&quot; rather than just &quot;decoration&quot; or meta-information. They have real effects on the truth values of sentences, but they don&#39;t change the predicate-argument structure or describe the scope trees (although topic can influence scope, according to Sanghoun&#39;s dissertation).<br></div></div></div></div></blockquote><div><br></div><div>I must admit I didn&#39;t test this with the current ERG.  Looking at the parses, the top-ranked parse has the ICONS link to &quot;Monday&quot; rather than &quot;on&quot;.  There are other parses with the link to a loc_nonsp, but I think these are introducing more predicates than necessary -- which reminds me of a previous thread: <a href="http://lists.delph-in.net/archives/developers/2018/002791.html">http://lists.delph-in.net/archives/developers/2018/002791.html</a>.  I still think this is a bug.  However, I&#39;ve found a much simpler example:</div><div><br></div><div>&quot;heavily, it rained&quot;</div><div><br></div><div>there is an ARG1 link from &quot;rain&quot; to &quot;heavy&quot;</div><div>and an ICONS link from &quot;heavy&quot; to &quot;rain&quot;</div><div><br></div><div>So do we write something like &quot;ARG1/EQ/focus-of&quot;, or do we have two links?</div><div><br></div><div>If we write them as separate links, I would be in favour of keeping *all* ICONS links separate.  If we want to have three-part arg/hcons/icons links, then I would be in favour of &quot;ARG1/EQ/focus-of&quot;.<br></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"><div dir="ltr"><div class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif"></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"><div dir="ltr"><div></div><div>Finally, we also need to consider cases where the ICONS link would go from a node to itself, which Sanghoun uses for e.g. &quot;the dog BARKS&quot;.  Again, I think there are two choices -- adding the ICONS as a feature on the node, or allowing links from a node to itself.  Using features complicates ICONS, but using links complicates the graph topology.<br></div></div></blockquote><div> </div><div><div style="font-family:arial,helvetica,sans-serif">Yes, that&#39;s also an interesting case. It&#39;s hard to test because I don&#39;t think the ERG uses text styling to determine information structure (e.g., BARKS or *barks*).<br></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>*Writing NEQ would go wrong in a case where there are three nodes (call them A,B,C) connected by two EQ links (A-B and B-C), and there&#39;s an ICONS-only link between the unconnected nodes (A-C).  However, I don&#39;t think this situation would arise.  An EQ link always points to the semantic &quot;head&quot;, so we would have to have A-&gt;B and C-&gt;B in the previous example.  I would be surprised to see an ICONS link between A and C, which are both modifiers of B.  e.g. with &quot;the brown furry dog barked&quot;, could we have an ICONS link between &quot;brown&quot; and &quot;furry&quot;?  With &quot;I saw the dog whose ears are brown&quot;, could we have an ICONS link between &quot;brown&quot; and &quot;poss&quot;?  I don&#39;t think either information structure or coreference could come into play here.  In the second case, it&#39;s easy to add information structure ICONS from &quot;saw&quot; to other nodes, but not from modifiers of &quot;dog&quot; to other modifiers.  Happy to be corrected if there&#39;s some other construction I haven&#39;t thought of!<br></div></div></blockquote><div> </div><div><div style="font-family:arial,helvetica,sans-serif">A -&gt; B -&gt; C happens with degree modifiers, e.g., &quot;the very furry dog barked&quot;, but I don&#39;t think we can get an ICONS between A and C (&quot;very&quot; and &quot;dog&quot;). But there will surely be cases that surprise us, whether due to obscure constructions or grammar bugs, and I hope the way we encode ICONS in the dependency formats is robust to these cases.<br></div></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif">One more case to consider is when one endpoint in an ICONS is an underspecified variable (e.g., i3) without a node. We had a discussion with Ann about this (off-list, unfortunately) where we decided to use &quot;unexpressed nodes&quot; with a special predicate name, e.g., &lt;node&gt;&lt;gpred&gt;__unexpr__&lt;/gpred&gt;&lt;/node&gt; only where they were necessary, but I don&#39;t think anybody implemented it in the end.<br></div></div></div></div></blockquote><div><br></div><div>Supposing we have __unexpr__ nodes, we don&#39;t need the ICONS links to behave any differently, right?  As in, if an ICONS target is a variable without a predicate, we just have an ICONS link to the __unexpr__ node.<br></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"><div dir="ltr"><div class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif"></div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr">Am Do., 26. Juli 2018 um 06:34 Uhr schrieb Michael Wayne Goodman &lt;<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>&gt;:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello again, developers,<div><br></div><div>With the upcoming ERG release including ICONS, I&#39;d like to make sure PyDelphin is ready to accommodate. Internally, PyDelphin has no trouble storing ICONS for MRS and DMRS (I believe they are discarded in the conversion to EDS, though), but I am only able to serialize them for MRS representations (SimpleMRS, MRX, Prolog, and MRS-JSON).</div><div><br></div><div>The last I heard, Ann had settled on a way of representing ICONS in DMRS as just a special kind of link, but I have not seen much as far as concrete proposals;. Does anybody have a link (the URL kind, e.g., to a wiki or presentation slides) that illustrates this method? The only thing I see is a proposal by Stephan on this list in 2016: <a href="http://lists.delph-in.net/archives/developers/2016/002200.html" target="_blank">http://lists.delph-in.net/archives/developers/2016/002200.html</a></div><div><br></div><div>If there is nothing &quot;official&quot; yet, can I just propose an adaptation of Stephan&#39;s &quot;variant (b)&quot; that changes dmrs.dtd like this (following existing conventions):</div><div><br></div><div><div>    &lt;!ELEMENT link (rargname, post, icons?)&gt;</div></div><div>    ...</div><div>    &lt;!ELEMENT icons (#PCDATA)&gt;<br></div><div><br></div><div>This allows &#39;ICONS: &lt; e2 topic x4 &gt;&#39; (in SimpleMRS) to be expressed as, e.g.:</div><div><br></div><div>    &lt;link from=&quot;10000&quot; to=&quot;10001&quot;&gt;&lt;rargname /&gt;&lt;post /&gt;&lt;icons&gt;topic&lt;/icons&gt;&lt;/link&gt;</div><div><br></div><div>Note: this allows icons to overlap with existing links; if there&#39;s no existing link, &lt;rargname&gt; and &lt;post&gt; are empty, as above (or we could make them optional on links).</div><div><br></div><div>In the &quot;slashed&quot; representation, we could add another slash only if ICONS are present:</div><div><br></div><div>* regular link: 10001:ARG1/NEQ 10002</div><div>* overlapping link: 10001:ARG1/NEQ/topic 10002</div><div>* ICONS-only link: 10001://topic 10002</div><div><br></div><div>Also note: in the above, I&#39;m making the assumption that there&#39;s only one or zero ICONS between any two individuals. It would be trivial to allow multiple &lt;icons&gt; elements in a &lt;link&gt; in the XML, but it&#39;s less clear how to do that in the slashed representation (maybe just a second, ICONS-only link). I also assume that the two ends of an ICONS are individuals that are the ARG0s of some EPs (i.e., not dropped arguments using &quot;i&quot; variables).</div><div><br></div><div>Lastly, is ICONS something that EDS should care about? EDS ignores scope (except during conversion), so maybe it doesn&#39;t worry about information structure (or other uses of ICONS) either? But if it does, how might it be represented?</div><div><br></div><div>Thanks</div></div>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-327269264548837050m_-1149072973006107619m_-5780607684991774357m_3665389053834872501gmail_signature">-Michael Wayne Goodman</div></div>
</blockquote></div></div>