-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
question about cf. in input #64
Comments
The reason behind it is the semantic meaning of 'cf.' in the name https://en.wikipedia.org/wiki/Cf. GNparser considers names with |
Yes, I understand what you mean.
No problems with that (if I do prefer to be risky, I could just remove " cf. " from the names in advance) But the same gnverifier logic should be applied to both specific and infraspecific ranks. Shouldn't it? You say Phacopsis cf. oxyspora should be matched to Phacopsis (and not Phacopsis oxyspora), |
looks like a bug in gnparser, adding an issue there |
I was wrong actually @abubelinha, gnparser suppose to stop parsing if 'aff.' used, while for 'cf.' we decided to parse name anyway, |
Some results of my Python calls to https://verifier.globalnames.org/api/v1/verifications/
Input 1: Phacopsis oxyspora var. defecta Triebel & Rambold
Bestresult: [Index Fungorum (5) 413758]: Phacopsis oxyspora var. defecta Triebel & Rambold 1995
Input 2: Phacopsis oxyspora cf. var. defecta Triebel & Rambold
Bestresult: [Catalogue of Life (1) 4FKN3]: Phacopsis oxyspora (Tul.) Triebel & Rambold
Preferred: [Index Fungorum (5)134632]: Phacopsis oxyspora (Tul.) Triebel & Rambold 1988
I would expect that with or without "cf.", the input should match the infraspecific rank.
But when "cf." is present gnames matched the next higher taxonomic rank (not sure if this is on purpose or not)
I have only seen this with infraspecific ranks input. With species input, that is not happening:
Bestresult: [Catalogue of Life (1) 4FKN3]: Phacopsis oxyspora (Tul.) Triebel & Rambold
Preferred: [Index Fungorum (5)134632]: Phacopsis oxyspora (Tul.) Triebel & Rambold 1988
May this be a bug, or should I take care of removing "cf." myself from input, to get my expected results in output?
I linked years above to a different question. Thanks!
The text was updated successfully, but these errors were encountered: