Dealing with pro parte synonyms

[mdoering]

While debugging Scarabs syncs I wonder how pro parte synonyms are dealt with? Maybe the actual data here is a wrong case, but generally we should face this quite often:

Gymnoloma Dombrow, 2001 seems to be a p.p. synonym linked to 2 different accepted taxa: Stigmatoplia (Dombrow, 2001) and Scelidothrix (Dombrow, 2001)

Ideally the source would just use one name record and 2 synonym records using that one name. That can only be done via ColDP though. The Clearinghouse normalizer does not try to normalize the 2 ACEF name duplicates into just one record - at this stage at least, maybe we should change that?

Does there need to be a decision type to merge the names and make them an "ambigous" pro parte synonym with 2 accepted taxa?

[yroskov]

CoL never dealt with synonymy above species in our old architecture. There was no such issue as "pro parte" in generic, family, etc. names. If you decide to include synonymy above species in a new architecture, you need to find a solution on how to deal with it. For example, synonymy on generic (and above) level turns to be very much complicated issue as soon as you switch from "nomenclatural synonyms" to "subset synonymy". In "nomenclatural synonymy" there is no such issue as "pro parte" at all, because synonymic name goes to the only genus, where type species go. The question is, what to do with a set of binomial combinations attached to the "old" genus, but they are not inside a subset around type species?

[mdoering]

Thanks Yuri. I wasn't specifically meaning generic synonyms. I agree this is opening up a can of worms. Let's just consider species. I assume you deal with them by assigning them the "ambiguous synonym" status, right? I guess the sync should in such cases make sure that ambiguous synonyms share their name records (remember we now have names separated from usages ie taxa or synonyms)

[mdoering]

If possible when generating the ColDP files please try to already share the same name with the relevant synonyms instead of duplicating the name

[yroskov]

Pro parte wasn't in a focus of CoL attention.
How we deal with pro parte bi/trinomials in old procedures: plants - we kept "p.p." comment in authorstrings and applied Ambiguous Synonym name status, if the name appears as a synonym with two or more species in the Catalogue. animals - (I do not recollect any cases of "p.p." comments in animalian checklists); in general case we applied Ambiguous Synonym name status, if the name appears as a synonym with two or more species in the Catalogue; name may have identical authorstrings (most probable pro parte case) or different authorstrings.

[mdoering]

Should we append p.p. automatically for botanical names in such cases? The backend knows about them.

[yroskov]

CoL software should not change GSD data (or change data for a minimum as possible). So, if GSD applies "p.p." marker, CoL+ software should parse it correctly, store in the system (in any appropriate place according its own structure and policy), and correctly publish "p.p." marker through user interface (we should minimize a chance of user's confusion).
If GSD does not apply "p.p." marker to the name, CoL should not add it, even, if CoL detects identical name with identical authorship somewhere else in the classification. Only neutral CoL name statuses should be used for flagging duplicated names.

[mdoering]

I think the main issue for me here is if we need a new decision type SHARE_NAME that if placed on a usage can point to another usage with which it should share the same name record.

[yroskov]

How to implement this, if two identical names (gen+sp+auth) came from two different GSDs, and the case is unresolved?

[mdoering]

if its unresolved its unresolved. But if you assign "ambiguous synonym" as a new status this is often and underlaying "shared" pro parte name I assume. And I would like to handle those better