Docs: Spelled-out numbers

[coltekin]

It may be a trivial question, but I could not find a direct answer or example.

In Turkish corpora, I see quite a few examples of numbers that are completely spelled out. For example, _otuz üç_ 'thirty three'. It looks natural to relate the parts with mwe. However, I saw (for example in English UD treebank) that the numbers like "three million" are marked using compound. This is not a good option for the above example, since it does not have a clear structure, but the decision becomes arbitrary, since we also see examples like _iki yüz_ 'two hundred', and gets difficult if it is _iki yüz otuz üc_ 'two hundred thirty three'.

As I understand, In METU-Sabancı treebank, these were joined together during tokenization.

I am inclined to mark all with mwe with a flat, head-final structure, but afraid of loosing the parallel with the other languages. (Motivation for head-final structure is the same as ones expressed in #189.)

[ftyers]

What is the problem with using compound ?

two hundred and thirty three 
compound(hundred, two)
compound(thirty, three)
conj(hundred, thirty)
cc(hundred, and)

Looks pretty ok to me ? Couldn't something similar be done for Turkish ?

[coltekin]

This looks good. The reason for my question was because the relation between _hundred_ and _two_ is not the same as the relation between _thirty_ and _three_. The first one (for me) has a clear head, but the second one does not. But your answer resolves it for me, the second relation looks more like a conjunction than a compound.

I was not thinking about conj since Turkish does not use an explicit conjunction. With a combination of conj and compound my preference would be:

iki yüz otuz üç
comp(yüz, iki)
conj(üç, otuz)
conj(üç, yüz)

It also captures the fact that it is 3 + 30 + 2*100.

Of course, if there is an already existing standard I'd rather follow it.

[jonorthwash]

I agree with the analysis of 2*100 + 30 + 3, where + is treated as conj and * is treated as compound or similar. Treating 30+3 (or 3+30, in this case, for some reason?) the same as 2*100 doesn't seem consistent.

[coltekin]

Choice of the order in '3 + 30' is arbitrary, like in other conjunctions. But it reflects that I want to mark it head final. Although the choice of head between 30 and 3 (or 100) is arbitrary here, if the whole numeric expression is inflected, the suffixes attach to the last number.

[ftyers]

Agree with Jonathan here. My post should have read:

two hundred and thirty three 
compound(hundred, two)
conj(hundred, three)
conj(hundred, thirty)
cc(hundred, and)

For Turkic, switch head-initial to head-final.

[dan-zeman]

Since Uppsala has confirmed that the conj relation must go left-to-right, head-final is not an option here (but there is no such restriction for compound).

Also I find it strange to analyze compound numerals as coordination, unless there is an overt conjunction as in English. I have tried to analyze all such examples just with the compound relation. (But I do not have many examples. Vast majority of numbers in the Czech data is expressed using digits. And sometimes the word for _thousand_ and _million_ is tagged NOUN, which also breaks the compound chains.

[coltekin]

Some more data on this: In Turkish, it is very common to use numbers as noted earlier.

Bin       dokuz yüz     on  dokuzda
Thousand  nine  hundret ten nine-LOC
In 1919

An overt conjunction is never used, but "understood". If there is a _ve_ "and" in between two numbers, these must be two different numbers. In spoken language, intonation would also indicate (I think) which parts are to be understood as conjunction (addition) and which parts should be compound (multiplication). Intonation is different for _dokuz yüz_ "9 * 100 = 900" and _on dokuz_ "10 + 9 = 19". For these reasons, the above proposal sounds quite appealing to me. Furthermore, we get a very clean way to map dependency relations to arithmetic nicely, which wouldn't hurt.

The direction of conjunction is not important for the representation of the numbers suggested above. However, for other reasons, such as the suffixes that are added to the last token, I still think the last conjunct should be the head for Turkish and for other languages for which it eases the use of the treebanks (see #236 for more on this discussion).

But there is one more issue with the conjoining numbers in Turkish. There is another very common usage where two or more numbers are coordinated without an explicit conjunct. But in this case, it means "or" or indicates a range with a hint of approximation

Üç      dört     kişi
Three   four     person
Three or/to four people 

For now, I have opted for marking the "or" usage with conj, and the numeric combination with conj:num. I am not attached to the labels or the exact solution, but I definitely agree with the "standard needed" tag above.

[dan-zeman]

FWIW, such “or/to” covert coordination of numerals exists in Czech, too. Here I would not object to conj, although we don't use it in UD Czech 1.2. The original treebank was not able to represent coordination if there was neither coordinating conjunction nor punctuation, which is this case. Therefore both numerals are attached to the same counted noun as nummod.

http://hdl.handle.net/11346/PMLTQ-VAWO

[dan-zeman]

Closing as obsolete. In UD v2, words of a number are connected via flat.

[amir-zeldes]

@dan-zeman this is currently not the case in English-GUM, which was modeled after EWT (both corpora currently use compound). This is convenient because then SD number can be converted directly to compound, and there's no need to ensure left-to-right. Is there a plan to change to flat in English/other languages? Also @sebschu

[dan-zeman]

I do not know what is the current situation in the individual treebanks. I know that the v1 guidelines recommended compound for this. But somehow this sneaked into the v2 guidelines for flat: http://universaldependencies.org/u/dep/flat.html#dates-and-complex-numerals

[amir-zeldes]

I don't think flat is a good idea here, as flat mandated left-to-right. In some complex numerals there might be a motivation to prefer one part (e.g. fraction is added to non fraction part of a complex number?) and certainly for dates. Maybe flat happens to work for the example:

1 December 2016

But if it's:

December 1, 2016

I think the head should be the day, and flat removes that option. In the latter case at least for English, I'm for:

compound(1,December)
nmod:tmod(1,2016)

This analysis basically says, there are multiple "MONTH 1" dates, and this is the December version: ((December) 1)

Does that make sense?

[martinpopel]

There is an open issue for dates: #455 (as well as several closed issues, e.g. #113 and #210).
I would suggest to discuss dates there and keep this issue for (other) spelled-out numbers.
Of course, taking into account e.g. the (not only Turkish) spell-out years, which are in the intersection of both issues.

[dan-zeman]

For spelled-out numerals, such as _four thousand_, flat seems better than compound exactly because it does not attempt to make one part the head. It may not be the preferred approach in all languages but I remember I was struggling with identifying the head when I was using compound in Czech, and I think there is no evidence of headedness in English either.

[amir-zeldes]

Doesn't four modify thousand? If I had to guess, I'd go with the normal Germanic right headed rule, and it fits nicely with German where it looks like a normal compound (viertausend).

[dan-zeman]

Well... possibly, yes. You could even say that it is nummod(thousand, four) (answering "How many thousands?"). But I don't feel strongly about it.

[amir-zeldes]

I think semantically it is 'counting', but syntactically it's more like a compound, at least if we consider "ten" in "ten year old" to be compound. This seems to have the same property of not pluralizing the modified number, since it is itself a modifier. It would be nummod for me in "she is ten years old" and "there are four thousands there".