carmls / snacs-guidelines

Semantic Network of Adposition and Case Supersenses: Annotation Guidelines
2 stars 0 forks source link

FOR every 10 you buy, you get 1 free #1

Closed nschneid closed 2 years ago

nschneid commented 5 years ago

A rate based on iterating over a set.

Reminiscent of:

nschneid commented 5 years ago

[Reddit task_001:997]

jenahwang commented 4 years ago

Any reason that "for_every" should be considered as a single target marked as RateUnit? para_cada i guess in spanish...

If not, then we need a label that allows for correspondence (#70 above) --- "as applied to" sense.

nschneid commented 3 years ago

This is hard. Let me discuss this one with Jena and @svivek in our next meeting.

nschneid commented 3 years ago

Aryaman: Exchange sense of FOR? Because you are being rewarded.

Removing the notion of rate which comes from "every":

However "for each" and "for every" seem pretty idiomatic as ways to express rate. Should they be MWEs?

For almost every bird I see I know what kind it is. (a regularity of correspondence, not necessarily a rate) (paraphrase: Whenever I see a bird I usually know what kind it is.)

Maybe the word "rate" is our problem, because it suggests a numeric quantity, and we should just interpret RateUnit as a relationship of recurrence.

nschneid commented 2 years ago

Another tricky one: "on average" (It takes people an hour on average). Putting Extent for now since it's kind of a hedge, but not sure that captures it very well.

I wonder if we should generalize RateUnit to something like SetIteration (whose temporal counterpart is Frequency).

Could also apply to "in general" (#25).

nschneid commented 2 years ago

Or we could simply broaden Extent to cover RateUnit and these other set-wise quantifiers.

nschneid commented 2 years ago

After discussion with @jenahwang: SetIteration seems better than RateUnit; concerned about overloading Extent too much.

nschneid commented 2 years ago

Just to throw out another option: if RateUnit or SetIteration is hard to justify because it's so sparse, what about applying the label Configuration for some miscellaneous cases just as we do for Temporal?

nschneid commented 2 years ago

Just to throw out another option: if RateUnit or SetIteration is hard to justify because it's so sparse, what about applying the label Configuration for some miscellaneous cases just as we do for Temporal?

Per @jenahwang, it's more frequent for Korean since the equivalents of "each"/"every" are adpositional.

Renaming RateUnit -> SetIteration seems like a good option.