[developers] ICONS in DMRS and EDS

[Guy Emerson]

Am Mo., 27. Aug. 2018 um 19:47 Uhr schrieb goodman.m.w at gmail.com <
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.
>

I'm convinced by your "very furry dog" example.  It seems not unreasonable
that there could be an ICONS link from "very" to "dog".


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

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"

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


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

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.


>
>
> 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/20180829/594b39f8/attachment.html>