search

isi-nlp / DiplomacyAMR

AMR-related aspects of Diplomacy ALLAN project
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

build-01 argument structure #1

Closed uhermjakob closed 2 years ago

uhermjakob commented 2 years ago

English: Build a Russian army in Moscow .

Result-oriented annotation:

(b / build-01 :mode imperative
      :ARG1 (a / army
            :mod (c / country :name (n / name :op1 "Russia"))
            :location (p / province :name (n2 / name :op1 "Moscow"))))

Process-oriented annotation:

(b / build-01 :mode imperative
      :ARG0 (c / country :name (n / name :op1 "Russia"))
      :ARG1 (a / army)
      :location (p / province :name (n2 / name :op1 "Moscow")))

Discussion: Both are reasonable. For consistency, we need to designate a canonical form.

uhermjakob commented 2 years ago

For Diplomacy, I'm mildly leaning towards the result-oriented annotation, because the new army will henceforth be referred to as

(a / army
      :mod (c / country :name (n / name :op1 "Russia"))
      :location (p / province :name (n2 / name :op1 "Moscow")))

and the above also more closely follows the structure in DAIDE.

But outside Diplomacy, the process-oriented annotation would be more natural.

jkkummerfeld commented 2 years ago

Either of these works, though I feel like the second is closer to how I think about it. Common messages are:

In these cases, the owner of the army is implicit, while the person doing the building is explicit, which is why the process-oriented annotation feels more natural to me.

ejwood19 commented 2 years ago

I also lean towards the process-oriented version based on intuition/"naturalness" for annotators (the location is the location of building, and only after completion is it the location of the unit).

But weighing against that might be examples of "hold". (1) "Hold the English army in Liverpool in place" vs. (2) "Hold the English army in Liverpool."

Similar "build", my intuition for example (2) is that Liverpool is the location of holding rather than the description of the army, but that means that examples (1) and (2) could have different AMRs. Which might then weigh on the side of result-oriented annotation for both "build" and "hold" examples for consistency.

uhermjakob commented 2 years ago

CONSENSUS OK, let's go with the process-oriented version then, as it seems more intuitive to annotators and is in sync with general AMR. I'll make updates to Diplomacy AMR corpora.

(b / build-01 :mode imperative
      :ARG0 (c / country :name (n / name :op1 "Russia"))
      :ARG1 (a / army)
      :location (p / province :name (n2 / name :op1 "Moscow")))
ejwood19 commented 2 years ago

I think we actually resolved this in the other direction - we agreed result-oriented is the simpler option.

uhermjakob commented 2 years ago

O dear. I don't think that we had a clear consensus for the result-oriented version. I realize that both Tess and Jono had second thoughts and that this is as close to a toss-up as it gets. (1) Given a sentence such as "Russia built an army in Moscow.", Jon May, Tess, Jono, and presumably the vast majority of annotators intuitively annotated or would annotate Russia as the agent of the building and Moscow as the location of the building. (2) This is how it is annotated in (regular) AMR. (3) This was (at least until 3 hours ago) the last written opinion by Tess and Jono on this thread. In my opinion, the situation for later actions such as move, support and retreat is sufficiently different.

jkkummerfeld commented 2 years ago

To sort this out, let's look at the build, move, hold, retreat, and convoy cases together. These are going to be our most common annotations and they all have a very similar flavour.

I assume build, move, hold, retreat, and convoy are all in Sara's doc, so let's look at that.

uhermjakob commented 2 years ago

@ejwood19 Could you elaborate what you mean by "result-oriented is the simpler option"? To me, it seems both options have similar complexity.

uhermjakob commented 2 years ago

Following up on Jono's comment. Comparison of build to move, hold, retreat, convoy and remove is useful, which is why I suggested the result-oriented option in the first place. move, hold, retreat, convoy and remove all use the (UNIT :mod POWER :location PROVINCE-OR-SEA) structure (see https://www.isi.edu/~ulf/amr/lib/amr-dict-diplomacy.html). However, I think that build on one side and move, hold, retreat, convoy and remove on the other side are only mildly similar. I would argue that one of the primary reasons for the (UNIT :mod POWER :location PROVINCE-OR-SEA) structure is its deictic resolution: Which specific unit are be talking about? Which specific army is being moved? Which specific fleet is being removed? For build, that's not the case because the unit initially does not exist and therefore does not need deictic resolution. The difference is also reflected in English articles: Move the Russian army in Moscow to Ukraine. Hold the Russian fleet in St. Petersburg. But: Russia builds an army in Moscow. I agree that the point is a valid argument in favor of the process-oriented option, but only a mild one, which, in my opinion, when weighed against how build is annotated in the general AMR corpus and the intuition of annotators, is not strong enough.

ejwood19 commented 2 years ago

I believe this is resolved, and for "build" we are using the process-oriented version (build :location) rather than attaching the location to the unit. Once the unit exists, it can be referred to by location.