[developers] ICONS in DMRS and EDS

[Guy Emerson]

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

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.

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.

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.



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


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180823/8bdf76be/attachment.html>