Template talk:Taxonbar/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Value of taxonbar template

Moved from User talk:Tom.Reding § Value of taxonbar template

This is not intended as a criticism of you, but I do not understand why the taxonbar template is of use when added to articles like Gonialoe variegata. The only database that is actually in line with the article, namely the World Checklist of Selected Plant Families, is not included. The Plant List, which is there, contains a very old extract from WCSP which is now well out of date. So the taxonbar contains a link which is just an out of date copy – the current WCSP information is at [1]. I can only assume that you don't actually look at the links you are adding – yet if these were separate external links it would have to be shown that each is relevant, and many of them clearly aren't. Peter coxhead (talk) 07:59, 23 October 2017 (UTC)

Here's another example. At Haworthiopsis pungens not only is the Plant List link out of date, but as with Gonialoe variegata, the IPNI link is wrong. It goes to the synonym, Haworthia pungens, and not the name used in the article, Haworthiopsis pungens. Peter coxhead (talk) 08:04, 23 October 2017 (UTC)

I'm afraid that's a result of the age-old garbage in, garbage out problem. {{Taxonbar}} gets its info from WikiData, so you'll have to update the information there. There could also be some transclusions which hard-code a species identifier (not on any pages I've edited though), but if WD info exists for that identifier, the WD info is used instead. And if no WD info exists for that page, the template hides itself.   ~ Tom.Reding (talk ⋅dgaf)  11:58, 23 October 2017 (UTC)

But my question is why we here, in the English Wikipedia, should be adding templates that pick up "garbage" from Wikidata. If I added an incorrect link, like one to the wrong species, as a separate External link entry, I would expect it to be reverted. So why is it ok to add such links within the taxonbar template? Shouldn't we be checking that the Wikidata data isn't "garbage"? Peter coxhead (talk) 14:58, 23 October 2017 (UTC)

Yes, we should be checking WikiData, and you (or anyone else) are encouraged to do so. WT:TOL would be a better and broader venue for that, as my experience with, and ability to semi-automatically update it (I am looking though), are limited.

The underlying question here is then: what fraction of {{taxonbar}}s produce "garbage", and what qualifies as "garbage", i.e. where > 50%? of the available links are too far off-topic? I'm far from being one to judge, of course. How about I pick 52 pages from the ~48k pages under Category:Species by IUCN Red List category (2 randomly chosen from each starting-letter, or perhaps fully-randomly), and we (perhaps the WT:TOL community) figure out how many of those are above and below the threshold? Jts1882, MCEllis, do you have any input?   ~ Tom.Reding (talk ⋅dgaf)  15:32, 23 October 2017 (UTC)

I had a look at Wikidata, and it seems to me that this is yet another example of where the design of their database is simply wrong. The entity Q15516206 is described as a species of plant, i.e. the entity in the database is the species. But the entity in many of the linked databases, certainly IPNI, WCSP, Tropicos and TPL, isn't the species but the scientific name. (Well, to be really accurate, it's fully the name in the IPNI, and partially the name and partially the taxon in WCSP, etc., which give lists of synonyms.) Haworthia pungens is the same species as Haworthiopsis pungens, but they are different names and hence rightly have different entries in IPNI. It's not possible as far as I can tell to set up the entry in Wikidata so that the one species (entity Q15516206) links to multiple names each linked to a different entry in IPNI, WCSP, etc. (This is the essentially the same problem that arises when you try to link articles which are divided differently in different wikipedias. We divide Berry and Berry (botany), but other wikis have only one article – Wikidata only allows you to link one of our articles to theirs.) Scientific names and taxa and the database entries that correspond to them simply don't have 1:1 relationships to one another, but Wikidata insists they do.

So it's not a case of "updating the information" at Wikidata – where there are actively used synonyms, it can't be updated. Peter coxhead (talk) 16:45, 23 October 2017 (UTC)

The question still remains: what fraction of pages in Category:Species by IUCN Red List category have this problem when it comes to {{taxonbar}}? If the error-fraction is, say, < 15% (subject to community discussion) I think the template is worth putting on, and having it removed from problematic pages.

Also: can these problematic pages be identified in some way? Perhaps through some wording or comparative testing in/within the article?   ~ Tom.Reding (talk ⋅dgaf)  17:00, 23 October 2017 (UTC)

Am I correct in understanding that you are adding the {{Taxonbar}} to taxa pages based on the IUCN red list pages. If so, the absence of the genus Gonialoe from the IUCN database suggests that the taxa is erroneously on the red list or that the name has been changed since it was added. Either way this needs to be flagged and the appropriate wikipedia article(s) corrected. The Taxonbar wikidata link takes it to Aloe variegata rather than Gonialoe variegata, which has a much sparser collection of links.   Jts1882 | talk  17:08, 23 October 2017 (UTC)

Yes, as I said at WT:TREE#iucn_id, or similar, would aid automation. I'll remove it from any genus Gonialoe pages I edited (3).  Done

Is there a way to further identify which pages can safely utilize {{taxonbar}}, or at least identify which pages it will not be useful on?   ~ Tom.Reding (talk ⋅dgaf)  17:16, 23 October 2017 (UTC)

The issue with Gonialoe variegata is that this is a recent name change from Aloe variegata. Many other wikis haven't caught up yet; we're ahead. The only way I can see to identify such problems is to look at the Wikidata entry. If you see that different scientific names are used for the same entity, then you know immediately that there is a problem, since the IPNI, WCSP, Tropicos, etc. links will be to only one of these scientific names and will be wrong for any wiki using another one. (Wikidata could be edited so that the link/identifiers match our scientific name, but then would be wrong for wikis using a different scientific name.) I don't know enough about the API to Wikidata to know whether you can automate the detection of different names; I suspect not, not least because in some cases articles are at the common name, which hides the underlying scientific name. Peter coxhead (talk) 21:40, 23 October 2017 (UTC)

Article titles using a common name aren't an issue as long as |taxon= or (|genus= & |species=) are available. The main issue is indeed semi-automating WikiData access just so I can perform a simple if-statement.   ~ Tom.Reding (talk ⋅dgaf)  22:32, 23 October 2017 (UTC)

Taxonbar improvements

@Peter coxhead: If you see such glaring issues with Taxonbar links, rather than shaking your fists in the air and demanding the removal of Taxonbar from a page, you could simply fix the problems by adding missing data to Wikidata and linking the Wikipedia article with the correct Wikidata item. Wikidata is a place to organize data, and experienced Wikipedia editors need to understand that contributing missing information to Wikidata will actually help improve Wikipedia articles and make the life of other editors easier. Wikidata should not be treated like it is some lab experiment gone wrong. I have addressed the issues and re-added Taxonbar to Gonialoe variegata. Of course things go wrong with taxonomy changes. Taxonbar now fully supports the latest WCSP, which I agree should be the standard Wikipedia follows for plant taxonomy. --MCEllis (talk) 02:22, 29 December 2017 (UTC)

@MCEllis: personally, I continue to regard the taxonbar template as pointless, but I have no wish to interfere with other editors who want to add it, unless it is wrong. Both of the links to Wikidata in the Gonialoe variegata article (the one in the margin and the one in the taxonbar) are wrong. They suggest there are no articles about this taxon in other wikipedias, whereas there are 17. The problem remains that Wikidata has no way of representing the fact that Q159136 and Q39719922 are one and the same taxon under different names. The least bad link is Q159136. Peter coxhead (talk) 09:26, 29 December 2017 (UTC)

A problem with Wikidata is that the entries are usually incomplete. There are properties for taxon synonyms (incorrect names), replaced synonyms (for nov. nom.), basionyms, and origin combinations (see WikiProject_Taxonomy). Normally synonyms seem to get added to the "also known as" element, which isn't really part of the data structure. I've added a replaced synonym statement to wikidata:Q39719922 (although it needs a reference), so the Gonialoe varigata item now has a link to the wikidata item on the name it replaced. This now indicates that they are the same species.

A second problem is that there is one Wikidata and many language Wikipedias. If other language Wikipedias point to Wikidata item of an old name, there doesn't seem to be a way of directing people to the newer name. What is needed is an "accepted name" property to add to the Aloe varigata item to indicate the name has been replaced. The WCSP database has multiple entries (490610 and 298109), but their page on the older name has a link to the new accepted name.

In lieu of an accepted name property, the reccommended approach is to use an "instance of synonym" statement. I've added one to the Wikidata item for Aloe varigata to indicate that it is an instance of synonym of Gonialoe varigata. This now seems to make the relationships between the two "taxa" clear both ways.   Jts1882 | talk  13:37, 31 December 2017 (UTC)

A question for Wikidata is whether the Gonialoe varigata item should point to other lanaguage wikipedia articles that haven't been updated (they are on the same species, just with a different name). If they are it will lead to inconsistencies between Wikipedias and Wikidata, but if they aren't there is consistency due to ignorance.   Jts1882 | talk  11:24, 29 December 2017 (UTC)

@Jts1882: my answer to the question you asked above is that the English Wikipedia article should link to all the other wikipedia articles on the same taxon – the articles are about the taxon, not the name. When editors could add inter-language links to articles, this is what we would always have done. But now that we have (foolishly in my view) handed this ability off to Wikidata, we are stuck with their incorrect data analysis and representation. So the least bad move is to link all the wikipedia articles to Aloe variegata (Q159136). Peter coxhead (talk) 12:23, 29 December 2017 (UTC)

@Peter coxhead, Jts1882, Tom.Reding, and Plantdrew: All of these are fair points (except for calling Taxonbar pointless), I agree with Peter that considering the setup we have now it would be best if all the Wikipedia articles remain linked together to the same Wikidata item, irregardless of taxonomy issues. So for Gonialoe variegata, it would be best to associate the article with Aloe variegata (Q159136).

IN ADDITION, it seems to me that Taxonbar should always be linked to the correct taxonomy. So on Gonialoe variegata, I would use the code {{taxonbar|from=Q39719922}}. Does this seem logical?

So you would see:

Instead of:

--MCEllis (talk) 15:39, 29 December 2017 (UTC)

@MCEllis: note that when you use the 'correct' Q39719922, taxonbar picks up fewer databases, because they haven't been updated to include the now accepted name.

What I think is needed to make taxonbar more useful is to be able to include Wikidata identifiers for all synonyms, given that the Wikidata entities are actually names, not taxa. We need syntax like {{taxonbar|from1=Q39719922|from2=Q159136}} which would then show multiple links to those databases that have entries for each of the synonyms. In default of that, you need to add multiple taxonbar templates to articles like Gonialoe variegata, one for each synonym that exists in Wikidata.

Unfortunately this doesn't solve the problem of the language links in the sidebar. Peter coxhead (talk) 15:59, 29 December 2017 (UTC)

I like the idea of |from1=, |from2=, etc., but that would just be a kludge. Surely WikiData:Taxonomy (what's the correct link, anyway? the one a few comments above is effectively a redlink) has had a discussion on this topic. Did they consider these possibilities?

Apologies, the link was working at one point but I must have changed something. The taxonomy properties in wikidata can be found at WikiProject_Taxonomy.   Jts1882 | talk  16:54, 29 December 2017 (UTC)

If we take the time & effort to enumerate all of the synonym IDs in taxonbars on en.wiki, we might as well do it in WikiData, and instead we would make a {{taxonbar}} parameter like |synonyms=yes (or |synonyms=no) that toggles synonym displays from whatever their default state would be. |from= could be a short-term stop-gap measure available for editors not familiar with WikiData (myself kind of included), to then be subsumed into WD by someone knowledgeable (we could even make a tracking category).   ~ Tom.Reding (talk ⋅dgaf)  16:29, 29 December 2017 (UTC)

I would not support mixing links of two different Wikidata entries into one Taxonbar. This would cause confusion. They would have to be clearly seperated, and possibly labeled as synonym identifiers.--MCEllis (talk) 17:34, 29 December 2017 (UTC)

Ok, so perhaps |fromN= is the right next step—case-by-case refinements, no large-scale changes/breakages/complaints/etc; a tracking cat would be nice/needed to easily keep track of which templates use |fromN=, though. We can take a look at the field after a while and go from there.

Now's a good time to continue/copy/move the convo to Template talk:Taxonbar or Module talk:Taxonbar (I'm not sure I'd be able to get any AWB editing done with a layout/cosmetic discussion on my talk...heh; I already have a few ideas too...). I'll leave what and how to copy/move to your discretion, MCEllis.   ~ Tom.Reding (talk ⋅dgaf)  18:57, 29 December 2017 (UTC)

Revisited

Peter coxhead & Jts1882, in an effort to create a short(ish) list of sorts where {{taxonbar}} has the highest probability of being useful, my time playing with the IUCN APIs might have helped. What do y'all think of this scheme for stricter placement of the template:

1. The taxon must exist in the IUCN database (Gonialoe variegata, Aloe variegata, Haworthia pungens, Haworthiopsis pungens, for example: all four do not).
2. The ID produced by this |taxon=/|binomial= IUCN lookup must also match the weblink lookup. I've found this to eliminate most of the WP pages (I haven't found any problem pages yet) that deviate from the IUCN, either by synonym or other discrepancy.
3. Avoid pages with {{Infraspeciesbox}} and its aliases.
4. Avoid pages with ({{Taxobox}} or {{Speciesbox}}) and (|subspecies=<something>, |trinomial=<something>, |binomial2=<something>, or |subdivision_ranks=(Sub)?Species).
5. Verify that the WikiData value for the IUCN ID matches the IDs in filter #2.

?   ~ Tom.Reding (talk ⋅dgaf)  22:42, 9 November 2017 (UTC)

This seems a sensible approach. Only add the Taxonbar when it adds at least one verified and useful source. I think the IUCN certainly qualifies for this, at least with animals and especially mammals. With plants it strikes me that the Kew WCSP checklist is the most suitable data source, but this isn't handle by Taxonbar. I saw somewhere that it was discussed but the discussion seemed to peter out after it was suggested that the Plant List already includes the information. From the comment by Peter coxhead above it seems that the Plant List version isn't updated as frequently. This suggests to me that it should be added to TaxonBar.

I have been looking at the reliability of the IUCN status entries in Wikidata and it seems they are very reliable. If the IUCN assessment name matches the Wikipedia page name (or a redirect) and the Wikipedia article points to a Wikidata item with an IUCN assessment statement, then the IUCN status and assessment link on Wikidata are correct (in all the cases I've tried). There are some IUCN pages where there is no corresponding Wikidata entry with an IUCN assessment (e.g. recently renamed species like Gonialoe variegata), but here the the information is not available rather than incorrect and your protocol wouldn't add the Taxonbar. A status mismatch sometimes occurs when the IUCN subspecies assessment redirects to an article on the species which has a different status overall to a rare subspecies, but the Taxonbar will point to the species item so there is no error on Wikipedia. There are also a few oddities where the common name (and Wikipedia article) covers more than one species assessed by the IUCN. However, these all fail to find a Wikidata IUCN status rather than yield incorrect results. If a Wikidata IUCN status entry can be found it is reliable.   Jts1882 | talk  13:25, 11 November 2017 (UTC)

Re: where the common name (and Wikipedia article) covers more than one species assessed by the IUCN, would my filter #3 or #4 apply to these pages, and, if not, is there a way to filter them out? I would argue that these pages have incorrectly used |binomial= or |taxon=. Is that correct, and is there a way to find them? Semi-automatically checking for an entry in WikiData is not an option unfortunately, as far as I know.   ~ Tom.Reding (talk ⋅dgaf)  13:42, 11 November 2017 (UTC)

My test ran for over 3800 mammals from the IUCN assessment list and checked wikidata for each. One of the mismatches was the Anoa, which includes species Bubalus quarlesi and Bubalus depressicornis. The {{taxobox}} used |binomial= and |binomial2=. The Wikipedia page pointed to Wikidata Q30571870, which is a sparce page with no useful information. My understanding is your scheme would find the Anoa Wikipedia page via the redirects. Checking I see you did add the taxon bar, which only has the Wikidata item. If you could also check Wikidata for an IUCN entry, you wouldn't add the Taxonbar without one.   Jts1882 | talk  15:07, 11 November 2017 (UTC)

I see, so you scraped the HTML of the WP page to find the WD ID? Then scraped the WD HTML for the species ID? Then I can check that that ID matches the IDs from filter #2?! Yeah, that's a hell of a kludge, but it should have a 0 or near-0 false positive %.

My scheme doesn't look at the redirects. It starts off by first looking at the |binomial= or |taxon=. If that doesn't work then it tries to create one using |genus= & |species=, assuming the subspecies giveaways in the other filters don't exist. When I was adding the {{taxonbar}} to Anoa, however, I wasn't aware of these issues, so I didn't perform any checks.   ~ Tom.Reding (talk ⋅dgaf)  15:35, 11 November 2017 (UTC)

I didn't use the HTML. I used the APIs for the IUCN red list, wikipedia and wikidata to get the data with a JS script, as follows:

1. Used the IUCN API to get a list of species ("/api/v3/species/page/1")
2. For each scientific name, used the Wikipedia API to get the wikibase item ("/w/api.php?action=query&format=json&prop=pageprops&titles=Panthera%20leo&redirects=1&formatversion=2&ppprop=wikibase_item"). The call handles the redirects from the scientific name to the appropriate Wikipedia page (same name, synonym or common name).
3. Used the Wikidata API to get data for the Wikidata ID ("/w/api.php?action=wbgetentities&format=json&ids=q140").

Then I just compared the wikidata values for the IUCN id (P627) and IUCN conservation status (P141) with the data from the IUCN.   Jts1882 | talk  16:43, 11 November 2017 (UTC)

Filter #5 added to use WikiData. I never knew about the WP & WD APIs! That's great! I'll definitely poke around a bit with them.

I prefer to start with the WP page text though, since that's the most straight-forward way, and the easiest way for anyone to double-check and/or fix. I've included |binomial2= in my filters too.   ~ Tom.Reding (talk ⋅dgaf)  17:53, 11 November 2017 (UTC)

Request

One thing I find valuable about taxonbars is the absence of expected databases. If I see that the taxonbar for a plant species doesn't display a link to The Plant List, it's likely that TPL treats that species as a synonym, or at best, unresolved, and Wikipedia should perhaps not have an article on that species. Absence of a taxonbar IUCN link is a real problem for anything that has an IUCN status. When I editd Taraxacum farinosum, it had an IUCN status, but it's not actually listed in IUCN. In my experience, this situation is usually the result of somebody copy-pasting a taxobox from a related species and neglecting to remove IUCN status parameters. Any chance you could filter for species with an IUCN status that aren't actually listed in IUCN? Plantdrew (talk) 04:28, 13 November 2017 (UTC)

Absolutely. I'm about to go through and add {{taxonbar}} to all pages under Category:Species by IUCN Red List category whose WD IUCN ID matches their actual IUCN ID. While I'm doing this I filter out many error cases, of which this is one. I've simply deleted the page from my work-list, though, instead of storing them. Kukumai, for example, gives a species name not found! error from the IUCN. Does that match what you're looking for?   ~ Tom.Reding (talk ⋅dgaf)  13:30, 13 November 2017 (UTC)

Not quite. I've since realized what I wanted to find probably isn't possible. Taxoboxes are typically generated by copy-pasting from a related species into a new article. Not infrequently, I find conservation statuses that have been inappropriately copy-pasted to a species where they don't apply. I was hoping to filter for articles that had an IUCN status (inappropriately), but which weren't actually in the IUCN database. But I don't think these cases can readily be separated from cases where the species is in the IUCN database, but under a synonymous scientific name. Plantdrew (talk) 15:29, 17 November 2017 (UTC)

This is doable and worthwhile. I think I can search IUCN for synonyms/aliases (need to double check that). Then I'll just need your help with refining what not/to filter. For example, how is Kukumai not what you're looking for (it seems to have an erroneous LC, that's for Chrysichthys grandis instead of Bathybagrus grandis)?   ~ Tom.Reding (talk ⋅dgaf)  15:40, 17 November 2017 (UTC)

Chrysichythys grandis is a synonym of Bathybagrus grandis. I understand you are being cautious and avoiding any cases where the scientific name used by the IUCN doesn't match the name used by Wikipedia, and taxonomic synonyms fall into that area. Gonialoe variegata aside, I don't think there is necessarily anything wrong with including IUCN status for cases where Wikipedia treats the name used by IUCN as a synonym. We definitely need to have a reference that establishes that synonymy though. I'm not sure if possible to easily separate the IUCN synonym cases from the copy-paste error cases I'm concerned about. Plantdrew (talk) 15:58, 17 November 2017 (UTC)

It wouldn't make any sense not to include IUCN assessments just because Wikipedia uses a different synonym. As you say, we just need a proper reference to verify the synonym. In many cases the IUCN assessment will provide that.

The IUCN API does provide searches for synonyms (/api/v3/species/synonyms/Chrysichthys grandis) and common names (/api/v3/species/common_names/Chrysichthys grandis). In this case it returns the common name Kukumai, but not the synonym Bathybagrus grandis. One thing to be wary of is a common name used for more than one species. Unfortunately, you have to know the name used by the IUCN, you can't use a synonym for find the relevant IUCN article. The new combination Bathybagrus grandis is the valid name according to Fishbase, which cites the Catalog of Fishes. However, Catalog of Fishes currently has Chrysichthys grandis as the valid name, as does FishwisePro. Fortunately, the wikipedia article uses the common name.   Jts1882 | talk  08:29, 18 November 2017 (UTC)

I have a list of ~800 pages which produced a "species not found!" errors from a little over half of the pages with a red list category. I'll remove the ones with a valid synonym to decrease the false-positive rate and post the results here.   ~ Tom.Reding (talk ⋅dgaf)  14:15, 18 November 2017 (UTC)

Of those 800, I was only able to straight-forwardly use the IUCN API to find the synonym for 1 page, Syncope bassleri. Very disappointing! Jts1882, I now see why you grab the redirects to a particular page. I suppose the only other alternative is to parse the text in the |synonyms= parameter, but that would get messy and presumably less reliable. (WP:ASTRO has a similar #R-structure for their oft-renamed meteors, but there is a preference for the most up-to-date name)

Plantdrew, this is still doable though. I could iterate through each of the redirects to each of the 800 pages, and remove one of the 800 if at least one of its #Rs has an IUCN match. If no IUCN match, via API and via #R-enumeration, that would qualify as a true-positive, yes? Jts1882, what would you say the false-synonym-rate is in this #R structure?   ~ Tom.Reding (talk ⋅dgaf)  04:03, 19 November 2017 (UTC)

Jts1882, any thoughts on this? Since you work with these #Rs, I'd like to get a "it'll probably work" from you before I invest more time.   ~ Tom.Reding (talk ⋅dgaf)  16:10, 1 December 2017 (UTC)

I'm a bit confused about exactly what you are asking. I assume #R means redirects. I didn't do anything explicitly with redirects as the wikipedia and wikidata API calls can be used with a redirect flag. I started with the IUCN scientific name (lists of a order or family) and the redirects find the appropriate wikipedia page when different names are used. This mostly helped with subspecies assessments by the IUCN. For instance, the 340 IUCN assessments in Carnivora returned 267 matches to wikidata. The redirect helped in 14 matches, four for species synonyms and ten involving subspecies. My understanding is that you are starting from wikipedia pages so I'm not sure this helps.   Jts1882 | talk  16:57, 1 December 2017 (UTC)

I'm about to start cycling through the #Rs (shorthand for redirects) to find relevant synonyms, as using the synonym API (and starting from the wikipedia pages) for these cases was essentially useless.

I'm most concerned about the thoroughness of the synonym #Rs, and if all (or most) pages have all (or most) of their synonyms as #Rs. I.e., if only 50%ish of pages have all of their synonyms #R'd, I probably wouldn't bother. It seems implied though, from what you've said on the matter, that this % is higher.   ~ Tom.Reding (talk ⋅dgaf)  17:22, 1 December 2017 (UTC)

Across all organisms, the number of synonym redirects is pretty low. Generally speaking, |synonym= in taxoboxes gets filled in before any redirects are created, and there are only 81,469 of 268,999 taxoboxes with |synonym= (granted, there are some species, mostly recently described, that simply don't have any synonyms). However, for species with IUCN assessments, I'd expect that the number of synonym redirects will be relatively high (~47k articles with manual taxoboxes have a {{para|status} and ~27k have both |status= and |synonyms=). Plantdrew (talk) 18:02, 1 December 2017 (UTC)

Welcome to Module:Taxonbar!

@Ahecht, Peter coxhead, Plantdrew, Jeanjung212, Snek01, SchreiberBike, Pigsonthewing, Izno, and Gaurav:

Thank you all for your interest, help, and support in this project. I have been working on the template today, and just switched all the code over to Module:Taxonbar. Hopefully the switch goes without a hitch! Keep an eye out for any issues that may arise.

Cheers!--Mellis (talk) 21:17, 28 December 2017 (UTC)

Mellis, just noticed a couple of pages with script errors in the module, two different errors: Penstemon barrettiae and Nyssorhynchus. Can you have a look to see where the problem lies with them? Thanks. --JohnBlackburne^words_deeds 19:51, 30 December 2017 (UTC)

@Ahecht: Could you take a look at these errors from Module:Taxonbar? Nyssorhynchus has a poor Wikidata entry, but it worked on that page prior to the switch. Not sure what it means.

Nyssorhynchus - New Taxonbar: (Now working, but hidden, see comments by Jts1882 below)

Nyssorhynchus - Old Taxonbar:

{{Taxonbar/old|from=Q24072911}}

Penstemon barrettiae - New Taxonbar (Why would it work here but not on the page?):

Penstemon barrettiae - Old Taxonbar:

{{Taxonbar/old|from=Q7164834}}

--Mellis (talk) 01:37, 31 December 2017 (UTC)

The second one is associated with the entries being explicit, i.e.

It works on the page with the parameterless taxobar.   Jts1882 | talk  08:28, 31 December 2017 (UTC)

I cannot think of any reason why the Nyssorhynchus wikidata had the title Nyssorhynchus Poinar (2005) [?]. I changed it to Nyssorhynchus and put added "Poinar (2005) [?]" to the description (it probably should be the reference for instance of). The taxonbar now works above with the module. On the Nyssorhynchus page it only works with the from parameter, but I assume this is temporary while background things catch up.

These are temporary fixes for those pages. The module needs to look for unusual page titles and handle the parameter lists.   Jts1882 | talk  09:07, 31 December 2017 (UTC)

Yes, the problems need to be addressed in the code. I unfortunately am no Lua master. Module:Taxonbar purposefully will should not display Taxonbar if there is only one identifier, which is the case with Nyssorhynchus. This does not change the fact that it couldn't handle the strange Wikidata title.--Mellis (talk) 14:34, 31 December 2017 (UTC)

I should add that the module Taxonbar above was showing the correct Taxonbar for Nyssorhynchu when I made the above edit. It now not showing now because I removed the NCBI Taxonomy ID from the Nyssorhynchu Wikidata item. This was referring to a mosquito, whereas this article is supposedly dealing with a Plasmodium subgenus with the same name. This seems to be entirely bogus. There is another Wikidata item for the real subgenus Nyssorhynchu (a mosquito subgenus) and an English wikipedia article on the Plasmodium dominicana (the subject of the article). The Nyssorhynchus article needs deleting, as should the wikidata item it seemingly spawned.   Jts1882 | talk  15:24, 31 December 2017 (UTC)

Nyssorhynchus now redirects to the parent genus of Mosquito, Anopheles. See Plasmodium dominicana for the Plasmodium.--Mellis (talk) 19:30, 31 December 2017 (UTC)

I was away over the holidays without internet access, so I'm trying to get caught up. I added some more error checking to the module, so it should be a little more tolerant now of bad titles or databases that don't have a formatter URL in Wikidata. (Note, the following sentences were modified from what I originally posted) The error with Penstemon barrettiae was due to the GRIN URL entry in Wikidata being of type "url", not "external-id", but an id number was being specified in the template call. In other words, if manually specifying the GRIN entry, you need to put the full URL, not just the identifier (this is mentioned in the template documentation, where the description of that field is the URL, not the identifier). This is why it worked when pulling from Wikidata, but not when manually specified. I've made the module tolerant of this sort of error, so it will now link to the database's homepage in these situations. --Ahecht (TALK
PAGE) 16:59, 2 January 2018 (UTC)

Taxonbar when Wikidata is using a synonym

Personally, I continue to think that {{Taxonbar}} is just clutter for the great majority of readers. However, if editors are going to add it to articles, it should be done correctly.

When the Wikidata entry is at a different scientific name to our article, usually at an older synonym, then the correct links can only be obtained by adding at least two taxonbar templates – the first should be for the Wikidata entity at the accepted name, hopefully the one under the name used in the article, and the second for the Wikidata entity that uses the synonym (or for each of the Wikidata entities that use synonyms if there are more than one). An example is Aloiampelos ciliaris. This doesn't, unfortunately, fix the problem that links to sister projects in the left margin of the desktop version of an article may missing, but it at least ensures that one of the taxonbar template entries correctly links to the taxon in one of the databases.

So when adding {{Taxonbar}}, editors need to check whether or not Wikidata has more than one entry for that taxon under different synonyms.

I would like to see this added to the documentation. Peter coxhead (talk) 08:01, 3 January 2018 (UTC)

Actually, I'm wrong in saying that it at least ensures that one of the taxonbar template entries correctly links to the taxon – for example, at Aloiampelos ciliaris neither template correctly links to WCSP, which is used as a reference in the article. Peter coxhead (talk) 08:07, 3 January 2018 (UTC)

That is because the Wikidata needed updating. I've updated the wikidata for the two taxon names, in what I think is the correct way.

I don't like the use of two taxonbars. It is not intuitive why and it isn't explained. If the information on synonyms is to be included, I think it should be within a single taxonbar. A second row could be added for the synonym (with a synonym parameter taking the wikidata id) and it could be properly identified as a synonym in some way (e.g. an extra column for accepted name/synonym).   Jts1882 | talk  09:46, 3 January 2018 (UTC)

As a quick and dirty fix, I added a "for" parameter to the sandbox that can be used for the the second taxonbar:

Adding a second row to the first bar would require a much more major re-write. --Ahecht (TALK
PAGE) 15:46, 3 January 2018 (UTC)

FYI I believe this is related to the #from# discussion above (under #Taxonbar improvements) moved from my talk. It's buried amongst a lot of other text, so I like that another discussion's been started. Just want to make it known to those not privy to it, and reiterate my support for a |from1=, etc., or |for1=, etc. parameter...how it gets displayed is another story.

I like Ahecht's solution. It would probably be good, if and only if a |from#=/|for#= parameter is present (and not null ofc), to be more explicit on the "parent" taxon identifier's row so that all lines say which taxon they are referring to.   ~ Tom.Reding (talk ⋅dgaf)  16:08, 3 January 2018 (UTC)

That is a big improvement as it explains what is happening. I would like to indicate the accepted name and synonym in some way to be absolutely clear, i.e to show the following information:

Perhaps replace "for" with two variables, say "accepted_name" and "synonym", which would allow different formating for the accepted name and synonym (as in your example.   Jts1882 | talk  16:16, 3 January 2018 (UTC)

The first version before the change. Tom's comment caught me in an edit conflict and I think we are suggesting something similar.   Jts1882 | talk  16:19, 3 January 2018 (UTC)

Left-justify that and I'm on board!   ~ Tom.Reding (talk ⋅dgaf)  16:35, 3 January 2018 (UTC)

Code-wise, |accepted-name= (without the "_") would be a more-standard parameter name; hopefully we can have multiple synonyms (but perhaps there should be a limit), and |synonym1= can be an alias of |synonym=, similar to CS1 parameter naming conventions.   ~ Tom.Reding (talk ⋅dgaf)  16:44, 3 January 2018 (UTC)

It's not consistent with WP:NPOV to just say "accepted name". Taxonomies are often disputed by biologists. You can only legitimately say "accepted by X", where "X" is a reliable source. I'm not aware of any dispute over the genus Aloiampelos but one well-known succulent expert, Gordon Rowley, sinks all Aristaloe and Gonialoe species into Tulista. In writing up Aloeae here I followed the World Checklist of Selected Plant Families, because we can only show one taxonomy in a taxobox, but it's not the only taxonomy for this group, and taxonbars in articles should not imply that it is.

However, I do think that showing the taxon names is a great improvement. Peter coxhead (talk) 16:58, 3 January 2018 (UTC)

To avoid any WP:NPOV issues, I just modified the template to recognize |from#= and |for#=. If # is greater than 1, it won't link "Taxon Identifiers":

I also took out the word "for", to make the group name a bit narrower. --Ahecht (TALK
PAGE) 16:59, 3 January 2018 (UTC)

To avoid NPOV issues, perhaps the Wikidata element should be removed from the list on the right to the description. What the taxonbar is showing is the taxon identifiers associated with the a particular taxon name in Wikidata. In Wikidata logic the taxon is a taxonomic opinion associated with the name. So each taxonbar is showing the taxon identifiers associated with Taxon Name (Wd:Q12345). Perhaps a seperate column would be best.   Jts1882 | talk  17:30, 3 January 2018 (UTC)

Sorry to keep on about this topic, but Help:Taxon identifiers needs changing a bit. As Jts1882 points out above, in many cases these are not "taxon identifiers" but "taxon name identifiers". The whole point of my issue with Wikidata is that there can only be one taxon identifier per taxon per database, otherwise they are "taxon name identifiers". In the World Spider Catalog, there is indeed one identifier per taxon. Thus if you search for "Sinopoda clivus", there's no entry, you just get a response saying that it's a synonym of Sinopoda koreana. In the WSC, there are indeed "taxon identifiers". The International Plant Names Index on the other hand is a database of scientific names; each name has an identifier, regardless of its synonymy. Aloe ciliaris is at 529326-1, Aloiampelos ciliaris is at 77125496-1. There are no "taxon identifiers", only "taxon name identifiers", because the whole point of the IPNI is to store information about names. To repeat myself yet again (and I'm sure boringly), it's precisely because the data analysis and representation in Wikidata fails to recognize the difference between a taxon and a name that all these problems arise. Peter coxhead (talk) 17:45, 3 January 2018 (UTC)

When you delve into Wikidata Taxonomy it is fairly clear that each Wikidata item is about the taxon name. When it declares the item to be an instance of taxon it really means it is about the taxon name, or more exactly a taxonomic opinion on the name. WCSP and ITIS do it the same way and their accepted name and synonym items can be compared to the Wikidata items. Wikidata expects the accepted name to be associated with a reference, so the Wikidata item on Gonialoe variegata is an item on the taxon Gonialoe variegata that is the accepted name according to the WCSP. This why think the Wikidata ID needs moving as it is the source of the definition for the list of taxon identifiers, not one of them.   Jts1882 | talk  17:57, 3 January 2018 (UTC)

Well, this isn't the place to discuss what I consider to be the muddled account at Wikidata Taxonomy. I'll only say that I cannot find a clear definition of the term "taxon". At one point there is "the same taxon (aka the same group of organisms)" implying that a taxon is a particular circumscription, although this is clearly not how the term is normally used, since it would mean that a monospecific genus is the same taxon as its only species, etc.

We can't treat Wikidata as a source in the English Wikipedia as per WP:UGC. Nor can we use the sources that Wikidata says are to be used: "when a taxonomic viewpoint needs to be referenced (and taxonomic viewpoints usually do need to be referenced), online databases generally are to be used only as a temporary measure. It is much preferred to use taxonomic literature as a reference." Not here, though, because the taxonomic literature will be a primary source, and we should be using secondary or tertiary sources, as per WP:PSTS.

My conclusion is that when we use more than one Wikidata identifier as the source of a taxon bar, we cannot distinguish between them other than by the name used. We cannot say that one is accepted and another not. (As an aside "synonym" has a different meaning in the ICN and the ICZN; the correct name in the ICN is not a synonym. It is a synonym, the senior synonym, in the ICZN; the ICN's synonyms are junior synonyms.) Peter coxhead (talk) 19:06, 3 January 2018 (UTC)

Alright, I bit the bullet and did a re-write at {{Taxonbar/sandbox2}}. {{Taxonbar/sandbox2|from=Q42729442|from2=Q138193}} produces:

Single-row taxonbars should appear as they always did, and |for= still works manually for both single- and multi-row taxonbars, but if omitted in multi-row taxonbars it pulls the name from Wikidata. I think I got most of the corner cases covered, but test it out and let me know if any problems pop up. --Ahecht (TALK
PAGE) 23:19, 3 January 2018 (UTC)

Yes, that seems to be working nicely and is a big improvement. I still feel having the second identity needs some explanation (why is the second name there?). One option would be to label it as a synonym, something like this:

While I agree that this is a POV of some authority, it is the POV taken by the Wikipedia article. The Wikipedia NPOV rules are about editors introducing their own POVs. An article text may describe various POVs of conflicting authorities with sources, but the article as a whole does take a primary point of view. This is reflected in the name of the article and in the taxobox where the accepted name appears as the taxon name and others as synonyms. Thus, as wikipedia articles do assume accepted names and synonyms, the taxonbars should follow suite for consistency and clarity. Different language wikipedia articles making different assumptions would handle the taxonbar differently according to their own intrinsic article assumptions. Anyway, if others disagree with me on this, I like the new version as it is.   Jts1882 | talk  08:10, 4 January 2018 (UTC)

If the taxobox lists the second (and any subsequent) names as a synonym, and gives a source (as it always should), then I accept that we can add "(syn.)" (not italicized, please) to the taxonbar, although I would personally prefer not to. It should be clear from the Taxonomy section in the article why the other names are there without the need to pick out one as not a synonym (in the botanical use of the term, not the zoological one). The other slight problem with adding "(syn.)" is that the name can be the accepted one in some of the linked databases, which appears inconsistent. I do like the new format with a single taxonbar template and 'box'. Peter coxhead (talk) 10:54, 4 January 2018 (UTC)

My reasoning was that from the taxonomic position taken by the article, the second item would be a synonym and could labelled such in a taxonbar in the article. The source is already in the article. However, let's leave the synonym out unless there is other strong support for including it. Progress has been made and we seem to have broad consensus for Ahecht's latest version.   Jts1882 | talk  14:14, 4 January 2018 (UTC)

Yes, I agree a lot of progress has been made and there is a broad consensus now. Peter coxhead (talk) 14:41, 4 January 2018 (UTC)

It looks great Ahecht! Nicely done.

What do y'all think about displaying "(alt)" as a less-loaded descriptor for the |for=s? Or is intuition (displaying no descriptor) the best way to go?   ~ Tom.Reding (talk ⋅dgaf)  17:56, 4 January 2018 (UTC)

I don't think that marking one or more names as "alt" is really less loaded. I'd either bite the bullet and accept Jts1882's point that the taxonbar can reasonably reflect the choice made for the article title, or leave them all unmarked, which I marginally prefer. Note that sometimes it may be our article that needs to be updated. Peter coxhead (talk) 19:07, 4 January 2018 (UTC)

1. In my view, Taxonbar should be collapsable if it becomes that large.
2. We should be careful not to say "accepted" name without a source. Wikipedia is not a taxonomic authority. Seems like we'd be creating a nightmare to use the "accepted" terminology.
3. @Peter coxhead: To me the solution to the separation of interlanguage links due to taxonomic difference would eventually need to be solved by a Wikidata bot searching for interwiki links on synonym marked entries, and moving all links to one Wikidata ID. It would be a big effort to sort out and automate. I think ultimately Wikidata was a good move for Wikipedia, but the massive side effect of not being able to handle Taxonomy correctly is currently a big problem that needs to be addressed. However, it doesn't help to simply be angry at the problem at not try to contribute the data that you know is missing from individual Wikidata pages such as WCSP links. ~ Mellis (talk) 20:18, 4 January 2018 (UTC)
4. (Additional edits) I like the '(syn.)' of the most recent sandboxed version. I think if we are going to try to display the information, we need to make it absolutely clear why we are displaying Taxonomic identifiers from two different Taxonomic names, and '(syn.)' accomplishes this well. ~ Mellis (talk) 22:23, 4 January 2018 (UTC)

@Mellis: I agree with your (1); it addresses my concern about "clutter". Your (2) – which I agree with – and your (4) are inconsistent in my view: calling some names "synonyms" and one not is really no different from saying that one is "accepted".

Re your (3): I'm certainly not "angry", although I admit to being exasperated – I have tried discussing this at Wikidata to no avail. (It's relevant that a key contributor to Wikidata Taxonomy is an editor who was eventually banned here – I've been told after causing many problems for WP:PLANTS editors, but this was before I started serious editing, so I have no personal experience. However, you can recognize plant articles originating from this editor, because if they haven't been fixed, they start "X is the name of a ..." rather than "X is ...", i.e. they appear to be about names not taxa.) I do edit Wikidata entries from time to time, particularly to try to get the interlanguage links working. Peter coxhead (talk) 22:43, 4 January 2018 (UTC)

@Peter coxhead: In my view, having two Taxonbars on Aloiampelos ciliaris is a cause of great confusion for readers. Even if both Taxonbars were labeled as Aloiampelos ciliaris and Aloe ciliaris, it would still not indicate why there are two Taxonbars. In my view, '(syn.)' explains this better and is more consistent with Taxobox, which lists synonyms. There is a big difference between using the term "Accepted" which implies Wikipedia has some kind of authority, and using the term "Synonym", which simply acknowledges that a taxon has more than one name. I can see why you might see inconsistencies in my argument, but I think my view here is consistent of current treatment of taxon names by en:Wikipedia. Wikidata is indeed a whole different animal, and yes, unfortunately it has had negative impacts on Wikipedia taxon articles, that could remain unresolved for years.

Then call all the names "syn." (which is strictly correct approach for ICZN names anyway). Peter coxhead (talk) 23:15, 4 January 2018 (UTC)

Hopefully this discussion eventually evolves into making Taxonbar work more harmoniously between existing systems in en:Wikipedia. If {{Taxonomy}} had a line that listed the correct Wikidata ID for that species name, Taxonbar could eventually pull data from {{Taxonomy}} so that it matched the names used by taxobox. Clearly the en:Wikipedia articles are not always linked to the proper corresponding Wikidata ID, as is the case of being purposefully linked to the wrong Wikidata item for consistency with interlanguage links. ~ Mellis (talk) 23:04, 4 January 2018 (UTC)

Species don't have taxonomy templates (other than in exceptional cases). Also it wouldn't solve the issue of there sometimes being multiple Wikidata items per taxon. Peter coxhead (talk) 23:15, 4 January 2018 (UTC)

I can see the argument that synonym is loaded, although I have also made the point that it is an assumption made by the article and taxobox. What about a simple as Aloe variegata for the second name? It indicates that it is referring to the same taxon under a different name without drawing any particular scientific conclusions.   Jts1882 | talk  07:39, 5 January 2018 (UTC)

Good idea! I'm happy with that. Peter coxhead (talk) 09:31, 5 January 2018 (UTC)

That's the strongest neutral wording yet. I like it find it passable.   ~ Tom.Reding (talk ⋅dgaf) 

I do not feel synonym is 'loaded'. As Jts1882 mentions, it is consistent with the rest of the article and Taxobox. The 'as' looks strange to me. @Plantdrew: thoughts? ~ Mellis (talk) 14:44, 5 January 2018 (UTC)

The new code is implemented in the main template. A hide link will show if there are more than two rows. I can easily modify it to add "as" if there is consensus. --Ahecht (TALK
PAGE) 16:10, 5 January 2018 (UTC)

@Ahecht: Did you try to make it collapsible? It doesnn't seem to be collapsible on Gonialoe variegata, for example, even though it would be nice. ~ Mellis (talk) 23:55, 5 January 2018 (UTC)

Here is another good example from American tree sparrow, I like the current look more than inserting 'as' before a taxon name. Having both inside one 'Taxon identifiers' box solves some of the confusion, but not all of the confusion of why two bars of links are shown ~ Mellis (talk) 00:22, 6 January 2018 (UTC):

Taxon labels of synonyms

@Ahecht: I've been using these synonym taxonbars a fair amount, good work! Could you change the navbox label of synonyms to retrieve taxon name (P225), rather than Wikidata entry titles/labels?, below are two examples where the current handling is an issue.
Cabbage:

Vappodes phalaenopsis:

Thanks, ~ Mellis (talk) 06:21, 14 January 2018 (UTC)

@Mellis: This is fixed in the sandbox:

Sandbox examples
Cabbage: Vappodes phalaenopsis:

The sanbdox version also makes sure that the item matching the current page title or wikidata ID the first one, and it removes duplicates. I also changed the "for" paramater to "title", to match the canonical name for this field, but I still support "for" to be backwards comaptible. --Ahecht (TALK
PAGE) 17:29, 15 January 2018 (UTC)

Lua Error

There is a error on the Coulter pine page :

 Lua error in Module:Taxonbar/conf at line 6: Tried to read nil global p.

--Cs california (talk) 06:46, 19 January 2018 (UTC)

Actually it's everywhere. I've commented out the call to Module:Taxonbar in {{Taxonbar}} until the Lua error can be fixed. Peter coxhead (talk) 09:29, 19 January 2018 (UTC)

It was a bad edit at Module:Taxonbar/conf that has been reverted. Johnuniq (talk) 09:56, 19 January 2018 (UTC)

Great, thanks to Ato 01 and you (I should have spotted that as the error trace was clear). Peter coxhead (talk) 11:51, 19 January 2018 (UTC)

Peter coxhead, you have broken the documentation inclusion with your last edit.--JohnBlackburne^words_deeds 17:14, 19 January 2018 (UTC)

@JohnBlackburne: actually, no, I was trying to fix it. Undone now, but the error is still there. Peter coxhead (talk) 17:22, 19 January 2018 (UTC)

There was an error in the Lua code that produced an error when displayed in the Template: namespace without any parameters (so it shouldn't have affected any articles). I have updated the module to remove that error.--Ahecht (TALK
PAGE) 18:06, 19 January 2018 (UTC)

@Ato 01, Peter coxhead, Johnuniq, Cs california, JohnBlackburne, and Zzuuzz: Good work all, {{Taxobox colour scheme}} was also hit by the same vandal and rescued. Thank you @Ahecht: for the many improvements to the module today! ~ Mellis (talk) 18:50, 19 January 2018 (UTC)

It's a little over year since I became actively involved in Wikipedia and it still amazes me the effort behind the scenes to create structures and fix problems. So many people put in so much effort that is invisible to the typical user. This is just one example of the efforts to make things work.   Jts1882 | talk  20:35, 19 January 2018 (UTC)

Hear, hear! I've been here for a while but it still amazes me how much gets done with so little fanfare. Keep up the great work here and elsewhere.  SchreiberBike | ⌨  23:50, 19 January 2018 (UTC)

Some more Links

Just a suggestion I think a Wikispecies link with a logo would go nice in this template. Any thoughts on this? I don't know Lua well enough to make edits though. --Cs california (talk) 06:28, 20 January 2018 (UTC)

Wikispecies is supported by Taxonbar via manually added parameters, Please read Template:Taxonbar/doc. We did not add the Wikispecies link to pages by default to avoid duplicate/excessive linking to Wikispecies on a page. In my opinion, a logo would not fit well with the design. ~ Mellis (talk) 01:36, 22 January 2018 (UTC)

Illustration of the value of multiple from parameters

The taxonbar at Aeonium aureum shows nicely the value of multiple from parameters. All three names will be found in books – the second is more common in the floras I have – and there are different and useful links attached to all three Wikidata items. It also shows very clearly again that these Wikidata items are not "taxa" as they claim, but "names". I do urge everyone adding {{taxonbar}} to articles to use the from parameter(s) – even if there is only one Wikidata item now, there could easily be another at a synonym in future. Peter coxhead (talk) 22:51, 30 January 2018 (UTC)