[developers] ICONS in DMRS and EDS

[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").

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/20180829/8066f380/attachment-0001.html>