[developers] ICONS in DMRS and EDS

[goodman.m.w at gmail.com]

Thanks, Guy, for the detailed reply and interesting examples!

On Thu, Aug 23, 2018 at 4:56 AM Guy Emerson <gete2 at cam.ac.uk> wrote:

> (Replying here rather than on
> http://lists.delph-in.net/archives/developers/2018/002803.html)
>
> I would generally support this.
>
> 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).
>

I cannot answer the "is there a need" question, but regarding the
serialization issue I can agree with having all on the same link joined
with some delimiter. Let's use your comma-delimited suggestion as our
working proposal.

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 (
> http://langsci-press.org/catalog/book/111), 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.
>

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.

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.
>

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'm not sure if ICONS are "structure" rather than
just "decoration" or meta-information. They have real effects on the truth
values of sentences, but they don't change the predicate-argument structure
or describe the scope trees (although topic can influence scope, according
to Sanghoun's dissertation).


> 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.
>

Yes, that's also an interesting case. It's hard to test because I don't
think the ERG uses text styling to determine information structure (e.g.,
BARKS or *barks*).

*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!
>

A -> B -> C happens with degree modifiers, e.g., "the very furry dog
barked", but I don't think we can get an ICONS between A and C ("very" and
"dog"). 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.

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.


Am Do., 26. Juli 2018 um 06:34 Uhr schrieb Michael Wayne Goodman <
> goodmami at uw.edu>:
>
>> Hello again, developers,
>>
>> 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).
>>
>> 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:
>> http://lists.delph-in.net/archives/developers/2016/002200.html
>>
>> 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):
>>
>>     <!ELEMENT link (rargname, post, icons?)>
>>     ...
>>     <!ELEMENT icons (#PCDATA)>
>>
>> This allows 'ICONS: < e2 topic x4 >' (in SimpleMRS) to be expressed as,
>> e.g.:
>>
>>     <link from="10000" to="10001"><rargname /><post
>> /><icons>topic</icons></link>
>>
>> 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).
>>
>> In the "slashed" representation, we could add another slash only if ICONS
>> are present:
>>
>> * regular link: 10001:ARG1/NEQ 10002
>> * overlapping link: 10001:ARG1/NEQ/topic 10002
>> * ICONS-only link: 10001://topic 10002
>>
>> 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).
>>
>> 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?
>>
>> Thanks
>>
>

-- 
-Michael Wayne Goodman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180827/9dcbc49b/attachment.html>