[developers] ICONS in DMRS and EDS

[Guy Emerson]

I would be happy with those proposals.

(I don't have a strong opinion about PENMAN, though, and I didn't even
realise there was a upper-/lowercase distinction here.  The explicit
:icons: namespace seems sensible to me.)

Am Mi., 29. Aug. 2018 um 23:53 Uhr schrieb goodman.m.w at gmail.com <
goodman.m.w at gmail.com>:

> (I abbreviated the replies below)
>
> On Wed, Aug 29, 2018 at 7:28 AM Guy Emerson <gete2 at cam.ac.uk> wrote:
>
>>
>>
>> Am Mo., 27. Aug. 2018 um 19:47 Uhr schrieb goodman.m.w at gmail.com <
>> goodman.m.w at gmail.com>:
>>
>>>
>>> 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.
>>>
>>
>> I'm convinced by your "very furry dog" example.  It seems not
>> unreasonable that there could be an ICONS link from "very" to "dog".
>>
>
> 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".
>
> 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:
>> http://lists.delph-in.net/archives/developers/2018/002791.html.  I still
>> think this is a bug.  However, I've found a much simpler example:
>>
>> "heavily, it rained"
>>
>> there is an ARG1 link from "rain" to "heavy"
>> and an ICONS link from "heavy" to "rain"
>>
>
> Thanks for the nice, simple example. I think you swapped the link
> directions, though (ARG1 from "heavy" to "rain", ICONS from "rain" to
> "heavy").
>

Yes, thanks for the correction!


>
> So do we write something like "ARG1/EQ/focus-of", or do we have two links?
>>
>> 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".
>>
>
> 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.
>
> 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:
>
>     (e2 / _bark_v_1
>        :ARG1 (x4 / _dog_n_1
>           :RSTR-H (q4 / _the_q))
>        :arg1 +)
>
> 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.
>
> 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:
>
>     10000:ARG1/NEQ -> 10001;
>     10000:focus -> 10001;
>
> For DMRX, we could use a new element:
>
>     <link from="10000"
> to="10001"><rargname>ARG1</rargname><post>NEQ</post></link>
>     <icons from="10000" to="10001"><relation>focus</relation></icons>
>
> 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.
>
>
>>> 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.
>>>
>>
>> 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.
>>
>
> 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.
>
> --
> -Michael Wayne Goodman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180830/f61b0a8b/attachment.html>