Docs: Punctuation in flat:name

[lauma]

I would like to ask regarding validator error if UPOS is 'PUNCT', DEPREL must be 'punct' but is 'flat:name'.

What is the appropriate UD style solution to handle person names with hypherns in them, e.g., Wiki lists quite a few of them https://en.wikipedia.org/wiki/Double-barrelled_name, company names like Hewlett-Packard and Yahoo!, rock band AC/DC, Europian Commission directive 80/987/EEC, law articles like Section 21002(b)(6)(B) etc.? Arguably some of these cases can be solved changing tokenization (consider punctuation mark to be part of larger token), but using it as universal solution might overcomplicate tokenization for parsers and other applications.

[arademaker]

We have already a long discussion about tokenization in https://github.com/UniversalDependencies/docs/issues/377#issuecomment-455531838

[lauma]

Thanks! I guess, I didn't express my self clearly. I wanted to know what should one do, when some longer flat:name (actually, flat:foreign, too) contains some kind of punctuation in case decision to not tokenize it as one word is already made for whatever reasons beforehand. E.g., _Montagu-Stuart-Wortley-Mackenzie_.

Is this the correct solution?

punct(Montagu, -)
flat:name(Montagu, Stuart)
punct(Montagu, -)
flat:name(Montagu, Wortley)
punct(Montagu, -)
flat:name(Montagu, Mackenzie)

Or can we do it like this?

flat:name(Montagu, -)
flat:name(Montagu, Stuart)
flat:name(Montagu, -)
flat:name(Montagu, Wortley)
flat:name(Montagu, -)
flat:name(Montagu, Mackenzie)

Because dashes are legitimate part of that name and someone named _Montagu Stuart Wortley Mackenzie_ might as well be completely different person with different name.

[amir-zeldes]

I agree with @lauma - punctuation can be a legitimate part of a name, in which case it isn't really punctuation at all. Consider also the ambiguity that making the distinction can resolve:

Clinton-Gore relations "Relations between Clinton and Gore" (two names, not flat, hyphen is punct)
Wortley-Mackenzie "A person whose name is Wortley-Mackenzie" (single name, everything is flat)

[lauma]

In case of flat:foreign and punct _veni, vidi, vici_ is probably good example - in non-Latin treebanks relation I would argue people use it as a fixed formula without thinking about comma use in Latin.

[dan-zeman]

Punctuation can be a part of a name, but that does not mean it's no longer punctuation. Elsewhere, punctuation is part of other things (coordination, subordination, apposition, parenthetical), yet it is still punctuation.

I think we need to shift the viewing angle: the flat relation has not been defined to capture every token that is part of a multi-word name. Instead, it often so happens that proper nouns within a named entity do not head each other and are thus a good fit for a flat relation. Unlike other tokens in the named entity, such as punctuation.

[amir-zeldes]

In general that makes sense, but I'm wondering how you would analyze Clinton-Gore vs. Wortley-Mackenzie - maybe just conj vs. flat on the lexical items? It would be nice to be able to distinguish them.

[nschneid]

Why not compound for Clinton-Gore?

[dan-zeman]

I would do conj(Clinton, Gore).

[nschneid]

I think it would typically be called an exocentric compound. Is there a policy that conj should cover these?

[amir-zeldes]

In German they're called copulative compounds, like strawberry-mango jam (the idea being that no one member is more prominent semantically, both strawberry and mango). I guess the paraphrase "strawberry and mango" or "Clinton and Gore" motivates a conj reading. It's not the same as 'and', but it's also not the same as other compounds, where the modifier constrains a head more narrowly.

[dan-zeman]

I may be mistaken but I do not recall seeing a similar example in the guidelines, either with compound or conj. Yet in English, conj seemed natural to me, for the reasons Amir gives. In other languages the situation may be different. The Czech equivalent of _strawberry-mango jam_ is _jahodovo-mangový džem_ where the fruit part is a compound adjective, not noun (or two nouns). It could be written even without the hyphen as one word, and _jahodovo_ is a form that cannot stand alone. Coordination would be _jahodový a mangový džem_ (fruits are still adjectives) and it would most likely refer to two jars with different sorts of jam. Hence I would do compound(mangový, jahodovo) in Czech. (As for _Clinton-Gore relations_, you probably would not use a hyphen at all, normal coordination is preferred: _vztahy mezi Clintonem a Gorem_.)

[tlynn747]

I'm reopening this issues as I didn't see a definitive answer for Lauma's question ... the discussion reverted to compounds (2-token discussion) instead.

We have many named entities in our Irish data that we want to label as flat (in the hope that our data can also be used to build a NER system in the future). Some of these are strings of multiple tokens that may contain a comma.

e.g. Roinn Gnóthaí Pobail, Tuaithe agus Gaeltachta -> Department of Community, Rural and Gaeltacht Affairs

The context for this NE in a sentence is "the program was updated and sent to the Department of ..."

Of course, as per Lauma's experience, the validation script doesn't allow for punctuation to be attached as flat. Yet if it's labelled punct then this interrupts the flat string labelling.

@dan-zeman for clarity - in your 14th February response, do you mean that a named entity can only be annotated with the 'flat' label if there are no two tokens within that entire string that can be assigned a head/dep relationship?

[sylvainkahane]

I really don't think it's a good idea to analyze _Roinn Gnóthaí Pobail, Tuaithe agus Gaeltachta_ as a flat structure if it has a similar structure to _Department of Community, Rural and Gaeltacht Affairs_. Such expressions have a very clear internal syntax. If you want to keep the fact that they are NEs add a label on their heads. But adding flat relations here would make the UD collection very heterogeneous.

[tlynn747]

Thanks for the reply @sylvainkahane. What do you mean by add a label on their heads?
Do you have an example from the French data?

[sylvainkahane]

We do not have annotated NEs, but only titles because they can have any POS as a head but behaves as PROPN. We have added a feature Type=Titleon them: examples sorted by the head's POS. We also added a feature EXTPOS=PROPN (external POS).

We didn't discuss the name of this feature on the UD list and I think this name is too vague (Type could be anything). As we already have PronType, NumType, etc, we could name this feature PhraseType (any suggestion is welcome). We also use this feature for MWE, because in SUD we decided to encode the internal syntax of MWEs when their internal syntax is clear enough : examples sorted by EXTPOS.

[amir-zeldes]

I agree with @sylvainkahane - entities and syntax can converge (flat), but often don't. Here are named entities in English-GUM containing punctuation, and a lot of them are not flat:

http://corpling.uis.georgetown.edu/annis/#_q=ZW50aXR5IC0-aGVhZCBwb3M9Ik5QIiAmICMxIF9pXyB0b2tfZnVuYz0icHVuY3Qi&_c=R1VN&cl=5&cr=5&s=0&l=10

We now use a MISC annotation Entity to indicate (potentially nested) entity spans:

https://github.com/UniversalDependencies/UD_English-GUM/blob/master/en_gum-ud-dev.conllu#L1071-L1076

[dan-zeman]

for clarity - in your 14th February response, do you mean that a named entity can only be annotated with the 'flat' label if there are no two tokens within that entire string that can be assigned a head/dep relationship?

@tlynn747 : Yes. But I would not formulate it this way. I would not say that a named entity is annotated with the flat label. The label belongs to a relation between two words. Regardless of whether the words do or do not belong to a multi-word named entity, the flat relation signals that it is not a head-dependent relationship. Multi-word personal names often contain relations of this kind, but other named entities often don't.

[arademaker]

I also agree with a proper syntax annotation of titles and names of entities like organizations. NER seems to be better a layer on top of the dependencies. The over using of flat in PT data had also the effect of decrease parsers performance that need to learn that in some context, determinants and other functional words are abnormally linked as flat to a token at its left side.

Regarding the additional information about POS tags, we have been using the MISC field for indicate that a MWE may have a specific POS as a whole, but maybe the features field is a better place. We reported it in the paper “Universal Dependencies for Portuguese” from 2017.

[dan-zeman]

MISC field for indicate that a MWE may have a specific POS as a whole, but maybe the features field is a better place

The FEATS field is not a better place than MISC if the feature pertains to a phrase rather than a single word (which is the case here).

[tlynn747]

Thank you all for your feedback and clarification. It looks like we'll need an overhaul of the use of flat in IUDT v2.7!

@arademaker thanks for the note on the effect on parsing. It makes sense once you point it out - and maybe the issue of punctuation was leading to my suspicion, rare labelling of punctuation as flat would also mess up parser accuracy. We'll take a look at that 2017 paper too thanks. Can you add it to the UD list of publications when you get a chance - we're currently writing something up ourselves and didn't come across it in our general search.

@amir-zeldes - thanks for the MISC link, we'll probably adopt that if @dan-zeman points out it's better to use that than features.
Can you point me to documentation that explains the numbering of the entities? Entity=organization-6)place-7)place-8) etc.

@sylvainkahane thanks for the Grew search link for the French data - we've been using Grew Match a lot but found it hard to pin-point this current search for proper noun strings.

[amir-zeldes]

Yes, I think if you want to include the entity type (rather than 'this is part of some entity'), then FEATS is not possible, since FEATS is normally a token-wise annotation, and the same token can belong to multiple entities of different kinds: [[UK] Prime Minister Tony Blair]

The numbers in the notation are only if you also have coreference (this is the conll-2012 shared task format). For corpora that don't have coreference, only the entity type is used, since, assuming proper nesting, it doesn't matter which opening (person bracket following a (person(person is being closed by person) - it's always closing a span from the most recent (person line.

For an example without coreference you can see the Coptic TB, though the word forms are in Coptic script:

https://github.com/UniversalDependencies/UD_Coptic-Scriptorium/blob/dev/cop_scriptorium-ud-test.conllu#L12

[arademaker]

@tlynn747 publication added in the page.

[tlynn747]

Go raibh maith agaibh - thanks both!

I'll close out the comment.