<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div></div><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">(I abbreviated the replies below)</div></div><div dir="ltr"><br></div><div dir="ltr">On Wed, Aug 29, 2018 at 7:28 AM Guy Emerson <<a href="mailto:gete2@cam.ac.uk">gete2@cam.ac.uk</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"><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" target="_blank">goodman.m.w@gmail.com</a> <<a href="mailto:goodman.m.w@gmail.com" target="_blank">goodman.m.w@gmail.com</a>>:<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"><br><div class="gmail_quote"><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's ostensibly true if there's no */EQ link, it'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'm convinced by your "very furry dog" example. It seems not unreasonable that there could be an ICONS link from "very" to "dog".</div></div></div></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">In this case, MOD/EQ/icons (rather than MOD/NEQ/icons) would work as it's not saying anything untrue (except what is implied by MOD), but I don't think this is a good idea because it weakens (the consistency of) our desired interpretation of "MOD".</div><br><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>I must admit I didn't test this with the current ERG. Looking at the parses, the top-ranked parse has the ICONS link to "Monday" rather than "on". 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" target="_blank">http://lists.delph-in.net/archives/developers/2018/002791.html</a>. I still think this is a bug. However, I've found a much simpler example:</div><div><br></div><div>"heavily, it rained"</div><div><br></div><div>there is an ARG1 link from "rain" to "heavy"</div><div>and an ICONS link from "heavy" to "rain"</div></div></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Thanks for the nice, simple example. I think you swapped the link directions, though (ARG1 from "heavy" to "rain", ICONS from "rain" to "heavy").<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 class="gmail_quote"><div>So do we write something like "ARG1/EQ/focus-of", 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 "ARG1/EQ/focus-of".</div></div></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">In this case I'm in favor of separate links for all ICONS, and then they wouldn't need to be <link> elements in XML. I don't want to introduce PENMAN-like -of edge inversion for DMRX or SimpleDMRS because it would complicate the interpretation of those formats.</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"> Speaking of PENMAN, it is perhaps the least expressive format we have (though it has its uses), due to it's tree-like shape. If we merge ICONS and regular links, how do we invert the argument edge but not the icons? :ARG1-EQ-of-focus? If we keep the regular links and icons separate, how do we avoid namespace collisions? Currently, properties are downcased and role names are upcased to help avoid problems when some blackhat grammar developer makes a grammar with ARG1 as a variable property:</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"> (e2 / _bark_v_1</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"> :ARG1 (x4 / _dog_n_1</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"> :RSTR-H (q4 / _the_q))</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"> :arg1 +)</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">But now what if that same developer made "arg1" the ICONS relation? Yes, this situation is unlikely, but even in the universe of good-citizen grammar-developers aware of such pitfalls, how do I tell (when reading these things and converting to MRS/DMRS) that, e.g., ":tense" is a property and ":focus" is an ICONS without having to consult the grammar/SEM-I? Maybe I can rely on node identifiers always being the target of ICONS but never of properties (unless, of course, the property value happens to have the form "x4" instead of "past"). Maybe explicit namespaces, like XML (:icons:focus x4)? Or we can just say ICONS aren't supported in the PENMAN format.</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">SimpleDMRS is not as expressive as DMRX, but at least node properties are not commingled with role arguments. With separate edges for ICONS, we could distinguish them from regular links by downcasing and/or by not using "/" in the relation name:</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"> 10000:ARG1/NEQ -> 10001;</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"> 10000:focus -> 10001;<br></div></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">For DMRX, we could use a new element:</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"> <link from="10000" to="10001"><rargname>ARG1</rargname><post>NEQ</post></link></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"> <icons from="10000" to="10001"><relation>focus</relation></icons></div></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">In summary, I think that separate edges for ICONS are best, but we need to take care with SimpleDMRS and especially DMRS-PENMAN to avoid creating ambiguous serializations.<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 class="gmail_quote"><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><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 "unexpressed nodes" with a special predicate name, e.g., <node><gpred>__unexpr__</gpred></node> only where they were necessary, but I don'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'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><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Yes, if we have the unexpressed nodes then ICONS should be able to use them happily. My point is that nobody (that I'm aware of) has an implementation that produces these nodes, so until we do we have no way to include these ICONS links in DMRS.<br></div></div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">-Michael Wayne Goodman</div></div>