Docs: Proper name as a lexical feature?

[Stormur]

I don't know if this topic has already been discussed, but apparently I could not find it in past issues.

So, I was wondering if the part of speech for proper nouns PROPN as separate from NOUN, ADJ, or others actually makes sense. In my experience, the "properness" just seems to be a semantic, or lexical property attached to an otherwise regularly behaving member of its class. It is true that in some languages, in some cases, the _syntactical_ behaviour can be different, but this happens also for "regular" nouns, e.g. in Italian:

• _Sono andato da Gianni._ 'I went at Johnny's'
• _Sono andato in università._ 'I went at the university'
• _Sono andato al negozio._ 'I went to the shop'

In the first two cases, neither the proper name _Gianni_ nor the common noun _università_ 'university' receive the definite article, whereas in the last case the common noun _negozio_ 'shop' does. Further, in many local varieties, or hypocoristically, or in other contexts still, proper (personal) names often receive an article:

• _Hai visto cos'ha fatto il Gianni?_ 'Did you see what Johnny did?'
• _L'opera più famosa del Manzoni..._ 'Manzoni's most famous work...'

So I think that in such cases "properness" is indeed involved, but that in general the behavioural variation (especially morphologically) is exactly the same as a NOUN in all respects.

Another issue is represented by the "common proper names" (I think they were touched upon in another discussion some time ago), which are indeed somehow addressed in the guidelines. I am OK with the fact that they are analysed by means of "regular" POSs (it would be difficult to do otherwise), but still they take on some behaviour of proper names, such as the entry in the Wikipedia:

• _Cat on a Hot Tin Roof is a three-act play..._

with no article, whereas (still from Wikipedia):

• _The cat (Felis catus) is a domestic species..._

To sum it up, my proposal is to move proper nouns from being a(n in my view) problematic part of speech to being instead annotated as a lexical feature, not differently than Foreign, Poss or Abbr. This way, probably it would be easier to tag longer strings of words (such as _Cat on a Hot Tin Roof_) as "proper". This would also allow to treat "proper proper names" and "common proper names" in a more homogenous and cleaner way.

[dan-zeman]

I used to share these doubts about usefulness of the PROPN category, but this battle was fought (and lost) back in 2014 when the v1 guidelines were being prepared. In some subcommunities the distinction between NOUN and PROPN was customary and it seemed that those people would like to have it. Now, almost six years later, there is a plethora of UD-compatible tools and datasets, so changing the set of 17 UPOS categories would have huge impact. I'm afraid that the benefits, if any, are not worth it.

[arademaker]

I don’t think this argument of compatibility should stop us to rethink decisions. Moreover, treebanks still have MANY variations and incompatibilities.

Finally, a possible change from PROPN to NOUM would not be very complex...

My 2 cents.

[olesar]

I think there are at list five types of the proper name/named entities constructions:1. single-word proper name (at present, tagged PROPN)  2. single-word common name, pronoun or adjective used as a proper name (e.g. Apple, the tagging policy can be different in different treebanks, especually in the case of (3) shortened to the single-word head)  3. multy-word nominal phrases with nouns as a prototypical head (tagged NOUN or PROPN)  4. (3) with an omitted nominal head (e.g. equivalents of adjectuves such as Old < Old Market)  5. clauses and non-nominal words or mwes (e.g. "As You Like It", "Never", "Hardly Working")   The PROPN/NOUN distinction can potentially apply to 1, 2, 3, and, ocasionally, 4. However, I am not sure that the grammatical behavior and diagnostic you describe holds cross-linguistically.

[nschneid]

Related discussion at #678

[Stormur]

@dan-zeman : I am with @arademaker in that there are still lots of incompatibilities between treebanks with regards to NOUN/PROPN, and I am convinced that the change I am proposing would help solve most of them. Besides, I don't think it would have such a big impact neither on tools (it is a mere reduction of a tagset involving mostly two largely overlapping tags) nor on treebank updating (the first step would be to just change all PROPNs to NOUNs, and it would largely suffice).
On the contrary, it would help e.g. in writing scripts or routines, removing a POS I always forget to include 🙂

@olesar : I am actually not sure to understand your point. In any case, I proposed this exactly as a way of streamlining cross-linguistical annotation! NOUN and ADJ categories are much less controversial than PROPN.

@nschneid : Sorry, this means I wasn't so attentive when searching for related discussions, and probably I was distracted by the "English" label.

---

PS: Now, I'm putting this here even if it would warrant a distinct thread, but in the same vein I would also be inclined to "demote" NUM to living on just the already existing NumType=Card on a DET. But I understand that this is less straightforward than the PROPN/NOUN issue...

[amir-zeldes]

@arademaker - wouldn't the easiest solution be to just add an optional feature Name=Yes and leave upos as is, so users can decide whether they consider PROPN a synonym of NOUN or not?

Even if converting PROPN to NOUN sounds easy in the technical sense, it may not work as expected in many cases, since some languages use PROPN for things that are not NOUN, possibly due to xpos guidelines and conversion from xpos (thinking of PTB guidelines and NNP). In that case, users might be willing to tolerate adjectives in a name being tagged PROPN, but seeing them tagged NOUN could actually be making the treebank worse in a way. Keeping PROPN and introducing a more fine grained feature could help distinguish the cases @olesar laid out, or at least give treebank developers a choice.

Besides, even if we had a perfect conversion of PROPN to all correct UPOS plus a feature in the FEATS column, there are still practical implications for all sorts of software using UD treebanks. For example, NER and coreference resolution systems often use POS tags to detect named entities, and even if the information is available in FEATS, they might not use that column. This might seem like a trivial problem, but we can't just say "they should simply look at the FEATS column" - there are lots of systems and developers out there, and a change like this would break all sorts of software that may or may not be well maintained.

[Stormur]

@amir-zeldes , I think that, whichever decision is taken, there should be left no ambiguity about PROPN vs. NOUN... as it happens now.

In that case, users might be willing to tolerate adjectives in a name being tagged PROPN, but seeing them tagged NOUN could actually be making the treebank worse in a way.

The problem here is that PROPN seems to be intended to mean "part of a proper noun", instead of a particular "syntactic word class". And as such, we could infer from a treebank that all manners of words (_hot_, _tin_, _on_) can belong to such a class, thus misleadingly duplicating many lemmas. So why tolerate an adjective tagged as PROPN, but not the same tagged as a NOUN?

---

Maybe I am quite radical, but yes, NER systems should also look at features, or better: it's not possible to consider all different ways all softwares work, especially if they look only at a portion of the information. Some will of course need to be rescripted. Others will benefit from this change. Also, an interesting question is: if a software is based on UD treebanks, why should it not also consider the FEATS column? Anyway, a software that just considers POSs, as of now, would not detect _Cat on a Hot Tin Roof_ as a proper noun...

[amir-zeldes]

The "part of a proper noun" thing is an issue stemming from the PTB tagging guidelines for English - it's not a fact about UD at large. What people do and don't tolerate in different communities is often a subtle issue, but when working on standardization (and I think that's what we're doing here, not just discussing theoretical linguistics), big breaking changes are something to be very cautious about in my opinion.

As for why software developers might not use FEATS: they may be trying to get uniform structure into a multilingual system, and many language TBs don't use FEATS, or use them differently. They may be using algorithms that don't support large numbers of features, or sparse features (every token has a POS tag, but Name=Yes would be rare). They might have built a system before FEATS was widely used, and the system is now no longer maintained.

Whatever the reason, we can't force people to adapt systems and we can't realistically do it for them either. It seems like a big change to force all UD treebanks to convert PROPN to NOUN + Name=Yes based on specific problems in specific languages. It's also very possible that PROPN is a very well-defined and justified category in some treebanks. It seems much easier to me to just allow people to add a Name FEAT to their treebanks if needed, and to treat PROPN and NOUN as the same if they like to.