Appropriate relation for -th, as in 4th, 5th, etc, when -th is a separate token

[AngledLuffa]

This is what happens in Urdu:

PART seems like a reasonable POS, but I find dep as the relation to be very unsatisfying. Is there a different relation type which would better represent the relation between 97 and th here?

In the Sindhi treebank, we'd usually been setting both the number and هين to NUM and having them point at the same head, but then I happened to notice that wasn't consistently done and wanted to unify the annotations to one standard. I'd be happy to unify them all to NUM (breaking with the Urdu treebank's analysis) if that seems like an okay approach.

The languages I can actually speak (even badly) tend to have -th annotated as part of the number, such as 4th, 第五, ...

[AngledLuffa]

@muteeurahman

[amir-zeldes]

I don't know anything about Sindhi, but for Urdu you could argue it should be goeswith and amod, since when these things are spelled out as words they are single tokens, even for larger numbers:

• Cardinal:
  • Five - پانچ - paanch
  • Twenty - بیس - bees
  • Twenty-five - پچیس - pachis
• Ordinal:
  • Fifth - پانچواں - paanchwaan
  • Twentieth - بیسواں - beeswaan
  • Twenty-fifth - پچیسواں - pachiswaan

So I don't think "waan" is normally something that should be considered a token, it's just an artifact of spelling the number part in Arabic numerals. At least for Urdu I would say it's still one "word" based on the examples above.

[muteeurahman]

Hmm, so the situation is mostly the same with Sindhi ordinals, which are single words—for example:

Urdu: پچیسواں, پچیسویں

Sindhi: پنجويھون, پنجويھين

Here, -ھون and -ھين are different case forms of the ordinal suffix (equivalent to "-th" in English). When these suffixes are combined with numerals—such as 25 واں 25 ویں in Urdu or 25 ھون 25 ھين in Sindhi a goeswith relation seems reasonable, provided that the NUM (number) and the "th" PART (ordinal suffix) can be linked in such a relation.

[dan-zeman]

I don't think goeswith is applicable if the spelling is correct according to the standards used in the language.

If it passess tests for wordhood and it is spelled with a space, it should be registered as an exceptional token with space and then it should be treated as one token.

[amir-zeldes]

I understand the view that it's problematic to use goeswith when it's not a typo, but I don't think these suffixes have 'word' status - it's like if English had an orthographic convention to spell "2 nd" with a space. However, I find exceptional tokens with a space very jarring and prefer almost any other solution to them... It's also problematic to put these in a list since they are productive (974 th). So if goeswith isn't an option, maybe flat?

If the only options for things that are not words by themselves are putting a space inside a token or using goeswtih without Typo, I would much prefer extending the definition of goeswith to mean "this is logically a single token but happens to be spaced out". In fact, the lack of Typo could be seen as saying exactly that: if the space is plain wrong we add Typo and CorrectSpaceAfter, if it's not wrong, we just have goeswith to mean "it's one token".

[nschneid]

Spaced numbers like "25 000 000" are already tokens-with-spaces, and those are productive. I would put "974 th" in the same category assuming it is conventional spelling for the language and the equivalent of "th" is not a word on its own. And the whole thing would be an ordinal ADJ.

There are other situations where an affix is exceptionally separated and we do need to use a deprel (UniversalDependencies/UD_English-EWT#152).

[dan-zeman]

... using goeswtih without Typo, I would much prefer extending the definition of goeswith to mean "this is logically a single token but happens to be spaced out". In fact, the lack of Typo could be seen as saying exactly that: if the space is plain wrong we add Typo and CorrectSpaceAfter, if it's not wrong, we just have goeswith to mean "it's one token".

No. Goeswith was always defined as an error in spelling but it did not always have these requirements on UPOS, LEMMA, and Typo=Yes. Then Nathan suggested and we in the core group approved these extra requirements, which became the historically first guidelines amendment in January 2022; then I implemented it in the validator and many people fixed it in their treebanks (while one treebank is now in the NEGLECTED category because of that change). Perhaps we could have instead widened the definition of goeswith back in 2022 (in fact I never knew what to think about having a special relation for a specific kind of an error) but not now. Changing a policy and then reverting the change after three years sounds like the opposite of the guidelines stability that UD wanted to achieve.