[developers] Dropped arguments in DMRS

[Michael Wayne Goodman]

I think we're all in agreement that the reduced clutter of DMRS and EDS is
a good thing. I brought up the ICONS and coindexed-dropped-arguments issues
as examples where the dependency representations are currently unable to be
equivalent with existing MRS representations, but I think we'd all agree
that we shouldn't just do whatever it takes to make them equivalent. More
below...

On Mon, Jan 11, 2016 at 1:22 PM Ann Copestake <aac10 at cl.cam.ac.uk> wrote:

> Hi all,
>
> On 11/01/2016 16:41, Stephan Oepen wrote:
> > if we were to add code to synthesize nodes for variables that are not
> > introduced as the distinguished (or characteristic) variable of any EP
> > but occur at least twice in an MRS, it would seem natural to me to
> > leave these nodes unlabeled (they will not have characterization or
> > other surface links either). this would also indicate that they have a
> > somewhat different status formally (at least in terms of
> > correspondences to a full MRS).
>
> we can't really leave them unlabelled in DMRS because they wouldn't show
> up very well ...  From my perspective, the alternatives to changing the
> DMRS code to allow them are 1. put zero pronouns back into JACY (without
> quantifiers) 2. add zero pronouns in some sort of post-processing step
> 3. add them to DMRS.  Mike mentioned ICONS - but it doesn't help here
> because the nodes that would have to be equated don't exist.  Or, at
> least, since ICONS can do absolutely anything, one could define a
> variant of ICONS which did encode it properly, but it's really too much
> of a stretch.


In MRS, the ICONS solution might look like:

RELS: < ... [ ... ARG1 i5 ...] [ ... ARG2 i6 ... ] ... >
ICONS: < ... i5 equal i6 ... >

where i5 and i6 are the dropped arguments that refer to the same thing
(i.e., instead of coindexing the variable on both arguments). However,
you're right that this would not naturally extend to DMRS, because it would
require the relation to encode the rargname of both the source and target
nodes. E.g., if we consider an extension to DMRS with <icons> as a sibling
element to <node> and <link> elements:

...
<icons>
  <iarg1 nodeid="10001"><rargname>ARG1</rargname></iarg1>
  <iarg2 nodeid="10002"><rargname>ARG2</rargname></iarg2>
  <ireln>equal</ireln>
</icons>
...

I know. Yuck. Also, such graph would no longer be simple nodes and links,
but instead nodes and links and icon-edges, which, at best, is harder to
explain to DELPH-IN muggles. It also feels like we're just flailing about
pretending to know nothing about the things we are equating.

So I now agree that the simplest and most enticing solution is some kind of
zero-pronoun, whether it's defined by the grammar (solutions (1) and (2))
or by the DMRS formalism itself (solution (3)). In addition, as you've
mentioned, a zero-pronoun would helpfully contribute a nodeid that could be
used for anaphoric pronouns in discourse, if that is something we'll need
later.

I believe the zero pronouns were dropped from Jacy precisely because of the
clutter. Japanese drops a lot of arguments, and each one could result in
two more uninteresting EPs (the zero pronoun and its quantifier). On a
related note, my work on computing MRS isomorphism found that a major
factor that caused inefficient computation was having many EPs with the
same predicates (e.g., lots of udef_q_rels). Therefore, I don't think it's
a great idea to reintroduce zero-pronouns in Jacy, unless we could
constrain it somehow (e.g., only for coindexation, without quantifiers,
etc.). I don't have strong arguments for choosing (2) or (3). With (2), it
might be easier to insert variable properties on the zero-pronoun (e.g.
evidenced from verb agreement, like the dropped subjects in Spanish or
something), while (3) can help keep the representation consistent across
grammars (since its defined by the formalism and not the grammar). (Aside:
Japanese doesn't have verbal agreement in terms of PNG, but it does encode
honorifics, even for dropped arguments. It would nice to keep this
information for the zero pronouns somewhere.)

Lastly, granting a nodeid for unexpressed arguments can help with other
ICONS relations (i.e., of the information structure kind, not the
variable-equating kind we were talking about before) where one of the
participants is unexpressed.

> i share your sentiment that the disappearing of unexpressed arguments
> > in our dependency graphs in general reduces clutter and is desirable.
> > co-indexation of such (unexpressed) variables admittedly challenges
> > that position.  if we end up special-coding for these cases, it would
> > be good to have the motivating examples and analyses readily available
> > (and publicly vetted).  i believe emily may have been the first to
> > argue for such co-indexation, probably from her work in the
> > grammarium?
>
>
> http://moin.delph-in.net/SingaporeMrsWellformedness
>
> the example Mike gave was tabe-sugiru = eat-exceed = overeat
>
> while it would be very good if someone could write this up or point us
> to a proper write up, I don't think there's much room for argument about
> needing it for Japanese, unless one uses zero pronouns
>
>
> >
> > —i recall we have talked once or twice in the past about adding an
> > explicit distinction of unexpressed variables.  for the ERG at least,
> > i believe dan (and others) often look at ‘u’ and ‘i’ (and maybe ‘p’)
> > as varible sorts that indicate unexpressed arguments.  but that is at
> > best a convention and prevents stronger typing of argument slots as
> > would be desirable.  for example, the ARG2 of _eat_v_1 presumably must
> > always be an ‘x’ when expressed, but dan abstains from putting that
> > type into the lexical entry because the scoping machinery would
> > complain at ‘x’-typed variable without a quantifier.
> >
> > would it work (and be desirable) to introduce a variable property, say
> > [ XP bool ], to distinguish expressed from unexpressed roles?  i
> > imagine it would not be hard to make all constructions that bind roles
> > specialize XP to true; one could then use the VPM machinery upon MRS
> > read-out to default remaining (unspecific) XP values to false.
> > alternatively, i imagine one could obtain the same effect by making
> > the hierarchy of variable types a little richer, i.e. put something
> > above at least ‘x’ and ‘e’ to indicate unxpressed variants, say ‘w’
> > and ‘d’ (the immediately preceding letters :-).
> >
> > any thoughts on actually introducing such an explicit marking of
> > unexpressed arguments?
> >
> > all best, oe
>
> The problem with handling unexpressed arguments `properly' is that there
> are multiple different classes of unexpressed arguments, as I outlined.
> In some cases in the ERG, verbs with optional arguments have unexpressed
> arguments in the semantics, while other cases don't.  This also
> interacts with the desire to save on predicate names that has caused
> many predicates to appear with different arities (which, of course,
> isn't OK if one translates directly to a conventional logical
> representation and has to be interpreted as some sort of notational
> convenience).
>
> e.g., the ERG demo gives:
>
> Kim understood understand_v_by (e, x, p)
>
> Kim understood the sentence / Sandy understand_v_by (e, x, x')
>
> Kim understood that Sandy was scared understand_v_by (e, x, h, i)
>
> Kim ran run_v_1 (e, x)
>
> Kim ran the race   / the store run_v_1 (e, x, x')
>
> Kim hoped hope_v_1 (e, x)
>
> Kim dreamed dream_v_1 (e, x, p)
>
> I don't find this intuitive but we don't have a test set or criteria for
> *MRS which would make it clear why one representation is to be preferred
> over another, and I find it hard to imagine what such criteria could
> be.  That's why I talked about anaphora in the previous message, since
> that could have been an example of a clear cut difference, though it
> seems (to me) it probably isn't.  Failing such criteria, I don't want to
> argue that there's a problem with the ERG representations but it also
> means that dropping them gives one less thing to worry about when we're
> actually using the output.
>
> So - I don't think it'll be a big hassle to add them to the DMRS code,
> but I don't propose to add them to the DMRS formal description and I
> don't think it's worthwhile expending energy on trying to clean this
> up.  There are ways to allow argument slot typing without messing up the
> scope machinery, if that's something that needs to be fixed.
>
> All best,
>
> Ann
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160112/723ef118/attachment-0001.html>