<div dir="ltr"><div>(Replying here rather than on <a href="http://lists.delph-in.net/archives/developers/2018/002803.html">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'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'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><br></div><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'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's book (<a href="http://langsci-press.org/catalog/book/111">http://langsci-press.org/catalog/book/111</a>), relative clauses introduce ICONS links from the verbs to the modified noun, so with "I saw the dog whose ears are brown", there would be both an EQ link from "brown" to "dog", as well as an ICONS link. So this could be written as MOD/EQ/focus-or-topic. But without the EQ link, I'm not sure. ???/NEQ/focus-or-topic.<br></div><div><br></div><div>We also need to consider cases where an ICONS link goes in the opposite direction to a regular link ("it was on Monday that it rained"). 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 "on" to "rain"), 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><br></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. "the dog BARKS". 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><br></div><div><br></div><div><br></div><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's an ICONS-only link between the unconnected nodes (A-C). However, I don't think this situation would arise. An EQ link always points to the semantic "head", so we would have to have A->B and C->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 "the brown furry dog barked", could we have an ICONS link between "brown" and "furry"? With "I saw the dog whose ears are brown", could we have an ICONS link between "brown" and "poss"? I don't think either information structure or coreference could come into play here. In the second case, it's easy to add information structure ICONS from "saw" to other nodes, but not from modifiers of "dog" to other modifiers. Happy to be corrected if there's some other construction I haven't thought of!<br><br></div></div><br><div class="gmail_quote"><div dir="ltr">Am Do., 26. Juli 2018 um 06:34 Uhr schrieb Michael Wayne Goodman <<a href="mailto:goodmami@uw.edu">goodmami@uw.edu</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello again, developers,<div><br></div><div>With the upcoming ERG release including ICONS, I'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 "official" yet, can I just propose an adaptation of Stephan's "variant (b)" that changes dmrs.dtd like this (following existing conventions):</div><div><br></div><div><div> <!ELEMENT link (rargname, post, icons?)></div></div><div> ...</div><div> <!ELEMENT icons (#PCDATA)><br></div><div><br></div><div>This allows 'ICONS: < e2 topic x4 >' (in SimpleMRS) to be expressed as, e.g.:</div><div><br></div><div> <link from="10000" to="10001"><rargname /><post /><icons>topic</icons></link></div><div><br></div><div>Note: this allows icons to overlap with existing links; if there's no existing link, <rargname> and <post> are empty, as above (or we could make them optional on links).</div><div><br></div><div>In the "slashed" 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'm making the assumption that there's only one or zero ICONS between any two individuals. It would be trivial to allow multiple <icons> elements in a <link> in the XML, but it'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 "i" 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'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>