[developers] labels, anchors and handles, oh my! (and ARG0s too)

[Joshua Crowgey]

Hi developers,

This is also a bit of a follow-up on the LAD regarding RMRS and
Lushootseed semantics (<http://moin.delph-in.net/LADLushootseedSemantics>).

I'm trying to understand some of the formal and theoretical
considerations regarding (R)MRS and their relationship to semantic
theory.  I think this comment from Dan (as transcribed by Emily) is a
good jumping-off point for what I want to talk about.

"""
Dan: You raised about 17 very good questions, and we probably don't have
time to work through all of them to any real satisfaction. Will try to
jump to the ones that seem most central. The labels on arg1 type baby
predications are not handles. Just a bookkeeping attribute saying that
these pieces fit together to make a normal MRS predication. Don't engage
in scope relations, etc. You are right to be wary of adding extra events
--- our neo-Davidsonian universe already gives us lots. The anchors in
RMRS are neither handles nor events. Just a bookkeeping technique to
allow us to navigate back and forth.
"""

I'm not sure if I think Dan is wrong, or if I it's just that I would
express this differently, but I might have said in contrast:

 * the labels "a" that we see on predicate names in RMRS are formally
the same thing as the "h" labels that we see on predicate names in MRS,
but are subject to a further constraints which "h" labels aren't subject
to (uniqueness)
 * the labels "a" *are* used to indicate scope relations.  In RMRS,
these scope relations are written down as "in-g" constraints.  These
in-g constraints refer to the "a" labels to (partially) describe a (set
of) scope tree(s).

Dan said:

"The anchors in RMRS are neither handles nor events. Just a bookkeeping
technique to allow us to navigate back and forth."

I think I agree, I've been thinking of "handle" or "anchor" as a
mnemonic to describe two usages of labels.  So "anchors" are labels just
as "handles" are labels.  And both kinds of labels are essentially a
bookkeeping technique, allowing us to refer to particular EPs (in RMRS)
or (in MRS) groups of EPs (although the groups might be singletons).
That is, I don't think there's supposed to be any direct theoretical
interpretation of labels, and we can use labels under different sorts of
interpretation frameworks for different purposes.  Different purposes
presuppose different constraints on how labels are handed out, and this
is why we call them "h" or "a" (to remind us of the constraints in play).

If you're still with me and I haven't said anything wildly obnoxious so
far, I'll keep walking farther out on this ledge.

I think where I'm really struggling here is in connecting the formal
elements of (R)MRS representation to the notions I find described in the
semantics literature.  As of the moment of this writing, it seems to me
like the items being represented in the (R)MRS are outnumbering the
concepts I want to use them to model.  More specifically, I understand
that we want a semantics which is based upon eventualities (events or
states, etc).  And in describing these eventualities in standard MRS, we
seem to use ARG0 on verb-like predicates (does this reify a
morphosyntactic notion like "verb" into our semantic model?!) to index
these events.  But I've had fingers wagged at me for trying to re-use an
eN index for my Lushootseed morphological transitivizers.  When I asked
why, I was told that one of the main reasons is to preserve
translatability into RMRS.  I presume this means that the translation
maps the unique es into the unique as of RMRS.  This seems to impose the
"bookkeeping" constraints which we impose on labels onto the
semantically contentful elements of the representation (the
eventualities indicates by the es).  In RMRS, I think the standard
representation for the role-relations in the "decomposed" EPS is to take
the anchor (the label) of the relation which introduces the
event(uality) as the first argument to the role relation.  Ie, we have
something like this:

a0:_ɬič̓_v_rel(e1)
a2:_arg1_rel(a0, x3 [PNG 3sg])
a4:_arg2_rel(a0, x5 [PNG 1sg])

Rather than something like this:

a0:_ɬič̓_v_rel(e1)
a2:_arg1_rel(e1, x3 [PNG 3sg])
a4:_arg2_rel(e1, x5 [PNG 1sg])

I have no idea why this is the case.  The only situation where the
former seems potentially problematic is where a0 has a relation which
has more than one e.  This might not be plausible:

a0: _multi_e_rel(e0,e1)
a1: _arg1_rel(a0, x2)

^^uh oh, is x2 the arg1 of e0 or e1?  Maybe e0 by convention.  Anyway, I
think I've rambled-on long enough that someone must be ready to set me
straight.  I'll try to summarize with this: (R)MRS seems to use labels
for decomposing eventuallity argument structure when I would have
expected it to just pass around the value of the relevant e.  What am I
missing?

Thanks very much for any insight.

--Joshua