Wikidata talk:WikiProject Taxonomy

From Wikidata
Jump to navigation Jump to search
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/05.

New proposal for CalPhotos taxon ID[edit]

Here's a new proposal for CalPhotos taxon ID: https://www.wikidata.org/wiki/Wikidata:Property_proposal/CalPhotos_taxon_ID. CalPhotos provides access to over 800,000 photos of plants, animals, fossils, people, and landscapes from around the world. AdamSeattle (talk) 04:45, 17 March 2024 (UTC)[reply]

Q374302 and Q25170208[edit]

copied from Help talk:Merge by author  TomT0m / talk page 09:24, 21 March 2024 (UTC)[reply]


house finch (Q374302) is older, but House Finch (Q25170208) is more detailed and has sitelinks. Special:MergeItems complains that the short names don't match up in every language; one of these uses the Latin name in every language, the other the common name. I'm not sure what to do here. Grendelkhan (talk) 22:25, 20 March 2024 (UTC)[reply]

@Grendelkhan Yeah, unfortunately, because the first item is based on the scientific name "Carpodacus mexicanus" and the second on the scientific name "Haemorhous mexicanus", they have to remain separate items per WikiProject Taxonomy's introduction text (some text was bolded in the original, some bolded by me):
As a result, there is not a single, universally accepted classification of the living world. For users of taxonomic information, perhaps the most frustrating consequence of this is that there can be multiple names for the same species. Most taxonomic databases will tell you which species name they prefer (i.e., which name they "accept"), and what is the "correct" classification for that species. But Wikidata includes information from multiple sources, and these sources may disagree on the accepted name for a species, hence to remain neutral Wikidata may have items for each alternative name for a species.
Monster Iestyn (talk) 00:49, 28 March 2024 (UTC)[reply]
@Monster Iestyn It could be possible to have several names on one item, however. author  TomT0m / talk page 08:51, 11 April 2024 (UTC)[reply]
Hi, similar to the separate pages for, eg, Global Biodiversity Information Facility (Q1531570) Felis leo & Panthera leo, there is one scientific name here per item, though the different items can be linked via taxon synonym (P1420), original combination (P1403), etc, Maculosae tegmine lyncis (talk) 09:00, 11 April 2024 (UTC)[reply]
I understand that, I just wanted to stress that I think in the Wikidata case the model is flexible enough to allow to do things differently and put several names in a single item. author  TomT0m / talk page 09:31, 11 April 2024 (UTC)[reply]

Proposal[edit]

Please see Wikidata:Property proposal/ASM Mammal Diversity Database ID - UtherSRG (talk) 16:58, 21 March 2024 (UTC)[reply]

New property proposal: Featherbase ID[edit]

As per Wikidata:Property proposal/Featherbase ID. Daniel Mietchen (talk) 21:40, 23 March 2024 (UTC)[reply]

Fossilworks not working, time to switch to Palaeobiology Database?[edit]

fossilworks.org has been consistently timing out for me since about two or three weeks ago. This means that all Fossilworks taxon ID (P842) and Fossilworks ID for this journal article (P7720) links do not work currently.

Though, considering that Fossilworks seemed to have been abandoned a few years ago anyway last I saw (various taxon pages appeared to have not been updated since 2020), may we take this opportunity to swap all Fossilworks links to paleobiodb.org instead? As in, start using Paleobiology Database ID (P10907) instead of Fossilworks taxon ID (P842), and create an equivalent identifier property for Fossilworks ID for this journal article (P7720). Monster Iestyn (talk) 12:28, 29 March 2024 (UTC)[reply]

I have been experiencing the same, for some time. In the instances I have checked, the Paleobiology Database ID (P10907) is the same as the Fossilworks taxon ID (P842). Is that always the case (if so, perhaps a bot could copy from one to the other)? Are there cases where there is/was a Fossilworks entry but there is no Paleodb entry? Maculosae tegmine lyncis (talk) 12:50, 29 March 2024 (UTC)[reply]
I haven't seen a case where the fossilworks doesn't have an entry with the same id number. There is at least one instance where PBDB has two IDs for the same taxon (46521) and 49734 for lion), although the entries are identical.
For the record there are only about 600 record with Paleobiology Database ID (P10907) compared to >10000 for Fossilworks taxon ID (P842) (is there an easy way to get the total on Wikidata, the what links here is different on en:Wikipedia). Jts1882 (talk) 14:16, 29 March 2024 (UTC)[reply]

IFPNI properties[edit]

IFPNI species ID (P6341) exists for species in the International Fossil Plant Names Index. It seems that there's no URL to find a taxon of any arbitrary rank in the IFPNI (as there is in the IPNI, for example). Thus Dillhoffia cachensis = urn:idName:ifpni.org:species:FA393F60-C14B-AC54-D82F-FA9E55CFAB08 and the entry is at http://www.ifpni.org/species.htm?id=FA393F60-C14B-AC54-D82F-FA9E55CFAB08, whereas Dillhoffia = urn:idName:ifpni.org:genus:2C090DE5-DEC7-8F8E-5327-010B4F8868FC and the entry is at http://www.ifpni.org/genus.htm?id=2C090DE5-DEC7-8F8E-5327-010B4F8868FC.

Given that the entries in the IFPNI for genera (and other ranks) are useful properties for instances of taxon (Q16521), it seems that either we have to

  1. require more of the URN as the identifier, e.g. species:FA393F60-C14B-AC54-D82F-FA9E55CFAB08 for Dillhoffia cachensis, and then construct the URL accordingly
  2. create more properties: IFPNI genus ID, IFPNI supragenus ID, etc.

The second option seems unattractive to me, but may be necessary.

What do others think? Peter coxhead (talk) 15:24, 31 March 2024 (UTC)[reply]

Perhaps a combination of 1 & 2. Keep the species id as is and create a new taxon id that includes genus and supragenus terms in the identifier. Jts1882 (talk) 15:44, 1 April 2024 (UTC)[reply]
Yes, that would be a good compromise, I think. I guess the full URN could be used if this was thought better than part of it. I don't have any experience of proposing a new property; I hope someone reading this will take it up. There are quite a few taxonbars in the English wikipedia that should have the IPFNI link for the genus. Peter coxhead (talk) 16:35, 2 April 2024 (UTC)[reply]

Handling of ambiguities with P9157[edit]

Hi everyone,

Recently, I have been importing a lot of Open Tree of Life ID (P9157), linked to Open Tree of Life reference taxonomy version 3.6 (Q124708476), following the modelling used by @Succu for the previous editions.

As preliminary word, I took the latest (v3.6) Open Tree Taxonomy (https://files.opentreeoflife.org/ott/ott3.6/ott3.6.tgz) and joined all OTT IDs to the mappings OTT has internally (so GBIF, NCBI, IRMNG, WORMS). For all taxa, if one (or multiple) of those were present, I added the corresponding OTT ID.

@Succu already made me aware of some entries which cause constraint violations: https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P9157.

This is because:

- If there are a GBIF ID and an NCBI ID linking to different OTT IDs on the same item, then it will end up having two OTT IDs

- If there are two different GBIF (or else) IDs on two different items linking to the same OTT ID, then this OTT ID will be present on both.

This is expected as the current modelling is about taxon names, so I guess this is OK.

More recently @VladXe also complained (https://www.wikidata.org/w/index.php?title=Topic:Y2gnduj9izdog3pl&topic_showPostId=y2gnduj9j3bqo7nt#flow-post-y2gnduj9j3bqo7nt) I consider these cases as expected and not faulty. I still stopped the upload before clarification.

Am I missing something here? AdrianoRutz (talk) 12:18, 8 April 2024 (UTC)[reply]

Online translation: Pseudomonadota ≠ Proteobacteria and the bot should take this into account. VladXe (talk) 15:53, 8 April 2024 (UTC)[reply]
I believe this is not reflecting the actual way taxa are modeled on Wikidata, as the items correspond more to taxon names than taxa.
The bot is adding external identifiers corresponding to these taxon names. And based on the external sources, what it does is correct. If you have a rationale to suggest to limit errors coming from them (such as not adding external IDs to items having a replaced synonym (for nom. nov.) (P694) statement as in your example, I will be happy to follow it but could not find any guidance about it so it should also be properly documented. AdrianoRutz (talk) 16:27, 8 April 2024 (UTC)[reply]

New Property Proposal: PlantZAfrica Plants of the Week ID[edit]

I've made a property proposal for PlantZAfrica Plants of the Week ID, which is open for discussion at https://www.wikidata.org/wiki/Wikidata:Property_proposal/PlantZAfrica_Plants_of_the_Week_ID. AdamSeattle (talk) 23:52, 11 April 2024 (UTC)[reply]

Update to discussion of synonyms[edit]

@succu, Christian Ferrer, Plantdrew, Strobilomyces, Peter coxhead, Daniel Mietchen: The previous discussion seemed to conclude with a call to create inverses of original combination (P1403) and basionym (P566). I have folded these into the tables of use cases of P642 ("of"), since the planned deprecation of P642 was the main reason for the discussion. Please review use cases i21, i22, and i23, making sure that I've 1) understood the consensus correctly and 2) captured all the affected statements in my queries, and if not, feel free to edit. And if/when one of you creates proposals for these properties, please update the table. Thanks! Swpb (talk) 14:51, 8 May 2024 (UTC)[reply]

  • For i21, taxon synonym (P1420) is, in my understanding, intended to be assymmetric, so personaly I would remove P31 = "synonym" only to replace it with main statement "synonym of", as for the two others. Why it is assymmetric? that's simple: almost all (if not all) external sources about taxonomy give it assymmetric, there is one "valid, accepted,.." name (according to one specific source) and possibly a list of synonyms for that name. Christian Ferrer (talk) 16:09, 8 May 2024 (UTC)[reply]
    • Ok, so changed. Obviously that asymmetry doesn't square with the lay meaning of "synonym", but I defer to you on its technical use in taxonomy. Swpb (talk) 18:30, 8 May 2024 (UTC)[reply]
My understanding is that, on wikidata, it is symmetric? Maculosae tegmine lyncis (talk) 18:59, 8 May 2024 (UTC)[reply]
  1. I think that the opinion of user:succu is very important since that person makes a lot of changes to these items.
  2. Our tutorial says that taxon synonym (P1420) is asymmetrical and so if P642 is going to disappear, we definitely need the "synonym of" property. That is what the table of use cases says, so that is fine. Personally I think that the data structure would be better if P1420 were symmetrical, but then we would need a "current name" flag to show which synonym was the real current one. I don't suppose that we can agree that change, so let's carry on with the new inverse synonym property.
  3. Our current synonym property, P1420, is named "taxon synonym" and therefore I think the name of the new inverse property needs to be "taxon synonym of" and not "synonym of". In my view, that is quite important in order to make clear that this property "belongs" to the taxonomy context. Unfortunately I myself proposed "synonym of" in the original discussion, but I think that that was a mistake.
  4. Subject to the change that i21 inverse property should be named "taxon synonym of", I agree with the three use cases as they now stand. Strobilomyces (talk) 19:55, 8 May 2024 (UTC)[reply]
Changed to "taxon synonym of" in the table. Of course, labels aren't set in stone even after a property is created. Swpb (talk) 19:27, 9 May 2024 (UTC)[reply]
Wikidata needs to be neutral with respect to taxonomy. So if one reliable source accepts X as the name of a taxon with Y as a synonym, and another reliable source accepts Y as the name of the taxon with X as a synonym, Wikidata must handle both views. So, yes, "taxon synonym" should be assymmetric in relation to a reliable source. The problem in reality is that the reference to the source is often missing. Peter coxhead (talk) 15:46, 9 May 2024 (UTC)[reply]
A citation needed constraint (Q54554025), with a constraint clarification (P6607) if needed, can be added to taxon synonym (P1420) and "taxon synonym of", and can even be specified in the latter's proposal, when someone creates it. Swpb (talk) 19:34, 9 May 2024 (UTC)[reply]
What are you telling us? --Succu (talk) 21:38, 10 May 2024 (UTC)[reply]
Peter coxhead was saying taxon synonym (P1420) and "taxon synonym of" statements should have references for which name is primary. I was just saying that's easy to enforce. Swpb (talk) 02:06, 11 May 2024 (UTC)[reply]

Different or Same?[edit]

Kindly requesting help with disambiguation please.

Are the below two items the same or different? And should they be merged?

They have different fossil works ID, one has an extra letter 'o' in its spelling, and have different parent taxon (P171), but the same taxon rank (P105) within the same branch. Wallacegromit1 (talk) 05:53, 12 May 2024 (UTC)[reply]