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

[Joshua Crowgey]

Hi Ann,

Thanks for the very helpful replies.  I have two follow-ups:

1) How do you build the scope tree with only anchors?  I understood the
example with the in-gs that I saw in one of your papers, but I don't
think I ran across the alternative way to constrain scope interpretation
(I may have simply overlooked it).

2) I think I'm really enticed by what you said here:

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

I think I've received this warning in the past---to be careful not to
conflate these ideas---but I don't think I ever found the rest of the
story.  If you find those slides, I'd really like to know more.

Thanks a lot for these helpful pointers,

--Joshua


On 11/04/2015 04:51 AM, Ann Copestake wrote:
> 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
>