[developers] ICONS

[Stephan Oepen]

hi again, once more!

> What I take from IconsSpecs is that support for ICONS involves extracting
> and outputting it and doing a check as part of generation (as described
> there).  Is there anything else?

in addition to these more mundane support measures, i would hope to
understand better over time (a) whether and how individual constraints
affect truth conditions (yes, presumably) and (b) whether and how they
interact with scope resolution (not, i hope, though without much
confidence).

in the ERG, i expect ICONS will replace relations like ‘appos’ and
‘id’ (e.g. in tag questions and identity coordination).  it was only
recently, that dan, emily, and i (in the ESD context) looked at how
the current placement of these relations in the scope hierarchy can
affect quantifier ordering.

for example, in 1214 there is a stark contrast in the number of
scope-resolved readings (eight vs. twenty-four) for the pair

  (a) john, the brother, hasn't met a linguist.
  (b) a linguist hasn't met john, the brother.

i am terrible at scope judgments, but i fail to see a good reason for
the lack of symmetry.  can it be motivated?

also, i have an intuition that the two instance variables linked by
the apposition should be treated as one for the purposes of scoping,
i.e. should not vary in scope relative to each other (or to other
operators).  but how to test that hypothesis?

—anyhow, regarding individual constraints in dependency graphs, i see
two candidate strategies: (a) create one dependency node per
constraint, make the constraint type the node label, and use edges
labeled LEFT and RIGHT (or so) to link to the nodes corresponding to
the two variables involved in the constraint.  or (b) merely represent
each constraint as a dependency edge, labeled with the constraint type
(which would presuppose label disjointness with the set of role
labels—a plausible assumption, in my view).

variant (b) is clearly more compact (fewer nodes and edges) but raises
the question mike asked a few days ago: there may or may not be other
dependencies between the two nodes involved.  for example, in
‘cookies, he likes’, i would expect the ‘cookie’ node to both be the
ARG2 of the ‘like’ node and its FOCUS (or something).  formally, i see
no problem with allowing multple edges (with different labels) between
a pair of nodes, but it would be something new for both EDS and DMRS,
i believe.  alternatively, one could use the DMRS ‘overlay’ technique
for parallel edges, e.g. unify the two into something like
‘ARG2//FOCUS’  from the point of view of using these representations
as targets for data-driven parsing, this would either increase the
label set or require a notion of composite labels.  thus, i would
probably prefer a solution with multiple, parallel edges.

ann, i am sure you have tossed around many of the same questions
already.  have you arrived at clear preferences already, one way or
another?  and ideally, can we relate these choices somehow to what is
known today about the formal status of individual constraints in full
MRSs?

good night!  oe