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

[Ann Copestake]

looks like I just replied to Joshua, rather than to the list, so here's 
my reply pasted below.  One more thing to add - there is perhaps some 
attraction to taking advantage of the ERG's proliferation of 
quantifiers.  We could give each noun a new ARG0 as its characteristic 
variable which corresponds to an eventuality (paraphrasable as `the 
state of being a teacher' for instance - it would be natural for 
adjectives like `former' to take this as an argument), making nouns look 
like adjectives, and make the old ARG0 of the noun the characteristic 
variable of the quantifiers.  This is nice in that variables in 
conventional logics are doing two rather different jobs - one being to 
tie predicates together, and the other to allow quantifiers to be 
interpreted - associating the variable with the quantifier would perhaps 
make this clearer. However, this would mean the DMRS looked even less 
like ordinary dependencies than they do now, and mean the rather 
surprising quantifiers like pron_q take centre stage in the structures.

Ann

> there aren't any in-gs in the `modern' form of RMRS (RMRS2) - just 
> anchors.  Anchors weren't needed in the version with in-gs. Handles 
> and labels in RMRS2 behave as in MRS. Arguments are attached to 
> elementary predications via anchors. Anchors are just identifiers for 
> elementary predications and nothing else - they disappear on RMRS->MRS 
> conversion and don't get involved in any relationships.  In DMRS, they 
> correspond to node-ids.
>
> One needs the anchor in general for things like relational nouns. 
> e.g., angry(x,z) & uncle(x,y) & teacher(y) can't be converted into 
> angry(x) & uncle(x) & ANGRED-SOURCE(x,z) & REL(x,y) & teacher(y) 
> because of the ambiguity of attachment of REL and ANGER-SOURCE.   But, 
> if one makes the characteristic variable assumption, then one doesn't 
> need both anchors and characteristic variables.  In DMRS, we just have 
> nodes. You could, I think, also define RMRScv with no anchors and 
> attach the arguments via characteristic variables (modulo some hack 
> for quantifiers).  I would be very careful about explaining what 
> you're doing in that case, however, because the notion of event used 
> by Parsons et al is not at all the same as the notion of 
> characteristic variable - the ideas overlap, but are distinct. I've 
> talked about this but not written it up - I'll see if there are some 
> slides somewhere which might be helpful.
>
> Best,
>
> Ann
>
> PS - again, apologies for inabilty to be properly involved right now 


On 03/11/2015 23:06, Joshua Crowgey wrote:
> 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