Jump to content

Template talk:Taxonbar/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6→Archive 9

Basionyms and synonyms

My experiences is that "synonym of" statements are much less often present on taxonomic items in Wikidata than "basionym" statements. More importantly, it may or may not be relevant to display some of the synonyms in the taxonbar – it could be confusing if they are not mentioned in the article, and based on the sources used in the article(s), we may not be accepting the synonymity of heterotypic/subjective synonyms. On the other hand, there can be no argument about synonymity of the basionym, and linking to it will often provide indirect access to the original literature in which the taxon was described.

So in my view a useful step is to automate adding the QID given as the basionym of a taxon (name) item as the value of the last from parameter in the taxonbar, if not already present. Peter coxhead (talk) 19:30, 7 April 2018 (UTC)

I'm gonna start thinking about how to do this, but if someone else codes it first (b/c it will probably require some floundering on my part), that's fine too.   ~ Tom.Reding (talk ⋅dgaf)  19:26, 8 April 2018 (UTC)
Peter coxhead, would 'with/without basionym' be useful tracking cats, or would that be going overboard?   ~ Tom.Reding (talk ⋅dgaf)  19:30, 8 April 2018 (UTC)
I think that would be going overboard. In a high proportion of cases, the taxon name is the basionym, e.g. a species that has never been transferred. Basionym information isn't that common in Wikidata even when it could be added. Further, because Wikidata doesn't use the correct format for the author(s) of a transferred taxon (for ICZN names it omits the parentheses that should be present, and for ICN names it omits the parentheses plus the basionym author(s) that should be present), there's no way of telling from within Wikidata that a basionym could be added. Peter coxhead (talk) 19:37, 8 April 2018 (UTC)
Peter coxhead (or anyone), can you show me a page with a basionym already on WD, for sandboxing purposes? Category:Pages using Wikidata property P566 (Q28039488) exists, but it's not obvious to me how to search through it...   ~ Tom.Reding (talk ⋅dgaf)  14:17, 9 April 2018 (UTC)
Found Sequoiadendron giganteum, already in the testcases!
I also asked at d:Wikidata:Project chat#How/where to search through Category:Pages using Wikidata property P#, b/c that's just silly.   ~ Tom.Reding (talk ⋅dgaf)  14:54, 9 April 2018 (UTC)
@Tom.Reding: another example is Ponerorchis cucullata, Ponerorchis cucullata (Q43372357), for which the basionym is Orchis cucullata (Q21977691). In this article, the taxonbar has the basionym in it (I added it myself). Peter coxhead (talk) 15:28, 9 April 2018 (UTC)

If you go to [1] and enter the following text in the right hand window, then press the big arrow in the left hand window, you'll get a table of the first 100 basionyms and their synonyms. 

SELECT ?basionym ?basionymLabel ?synonym ?synonymLabel WHERE {
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  ?basionym wdt:P31 wd:Q16521.
  ?synonym wdt:P566 ?basionym.
}
LIMIT 100

Peter coxhead (talk) 15:28, 9 April 2018 (UTC)

The query language is a kind of SQL. Ignoring the labels, in words it means "select every basionym and synonym pair such that basionym's instance_of property (P31) has the value taxon (Q16521), and synonym's basionym property (P566) has the value basionym". Peter coxhead (talk) 15:36, 9 April 2018 (UTC)

@Peter coxhead: good grief. Ok, bookmarked ffr...
@Tom.Reding: good grief indeed! Wikidata is a curious beast; from my perspective as an academic computer scientist it's a not-always-very-well-designed relational database wrapped in a clunky interface. It's certainly not at all user friendly in my experience. Peter coxhead (talk) 09:27, 10 April 2018 (UTC)
Also, the basionym appendage is now live. Let me know if any issues. Would it be desirable to label/identify these automatically-appended names in some way?   ~ Tom.Reding (talk ⋅dgaf)  00:08, 10 April 2018 (UTC)
WSCP marks basionyms with an asterisk; I suppose we could do this when there are multiple names, but if so it should be possible whether or not it's added automatically. I think I wouldn't do this at this stage. Let's see how it works out. Peter coxhead (talk) 09:27, 10 April 2018 (UTC)
Peter coxhead, I've expanded the basionym-is-an-instance-of-taxon check to include monotypic taxon (Q310890), fossil taxon (Q23038290), monotypic fossil taxon (Q47487597), and ichnotaxon (Q2568288), which I think was uncontroversial. I'm not sure about the others, so if you feel any of them are ok to uncomment (or you know of any others not listed) please do so.   ~ Tom.Reding (talk ⋅dgaf)  12:44, 15 April 2018 (UTC)
@Tom.Reding: seems fine as it is to me. I'm still very impressed when the basionym loads automatically! Thanks again. Peter coxhead (talk) 16:30, 15 April 2018 (UTC)

Coding

Ahecht, what I've tried to do is grab the has basionym (P566) statement, which should resolve to a WD page title, i.e. 'Wellingtonia gigantea' for Sequoiadendron giganteum (Q149851), and run that through mw.wikibase.getEntityIdForTitle to get its QID, then append the QID as an additional, incremented, 'from' to the parentArgs table. Problem is I don't know how to even extract the basionym statement... Keep getting nil. Could you help?   ~ Tom.Reding (talk ⋅dgaf)  16:12, 9 April 2018 (UTC)

@Tom.Reding: it's probably not relevant, but Wellingtonia gigantea (Q17363934) isn't set up as an instance of taxon (Q16521). I would use a more clearcut example for testing. Peter coxhead (talk) 16:21, 9 April 2018 (UTC)
I see..."instance of...unavailable combination"... Still relevant though (after the nil thing gets cleared up) - testing for "instance of...taxon" will be an additional check before adding it. Ponerorchis cucullata (Q43372357) > basionym Orchis cucullata (Q21977691) is indeed a better example.   ~ Tom.Reding (talk ⋅dgaf)  16:31, 9 April 2018 (UTC)
@Tom.Reding: The QID of the first basionym of subjectItem is 
subjectItem:getBestStatements('P566')[1].mainsnak.datavalue.value.id
subjectItem:getBestStatements('P566') is a table, so if you want more than one value, you could interate through it:
for _, basionymItem in pairs( subjectItem:getBestStatements('P566') ) do
  parentargs['from'..(fromTitleCount + 1)] = basionymItem.mainsnak.datavalue.value.id
  fromTitleCount = fromTitleCount + 1
end
--Ahecht (TALK
PAGE) 19:01, 9 April 2018 (UTC)
Thanks Ahecht, that did the trick! Where's the best resource for figuring out the data structures behind that & other statements/properties/etc.?   ~ Tom.Reding (talk ⋅dgaf)  00:08, 10 April 2018 (UTC)
@Tom.Reding: The documentation is at mw:Wikibase/DataModel/JSON. However, since that is usually incomplete, I usually just download the json file directly (e.g. http://www.wikidata.org/wiki/Special:EntityData/Q43372357.json) and re-indent it using Notepad++. In this case, the "P566" statement (with the references cut out) looks like:
JSON code
{
	"P566":[
		{
			"mainsnak":{
				"snaktype":"value",
				"property":"P566",
				"datavalue":{
					"value":{
						"entity-type":"item",
						"numeric-id":21977691,
						"id":"Q21977691"
						},
					"type":"wikibase-entityid"
					},
				"datatype":"wikibase-item"
				},
			"type":"statement",
			"id":"Q43372357$B7D4372C-17C0-4AD3-94AE-3F6B328663F2",
			"rank":"normal",
			"references":[]
			}
		]
	}
--Ahecht (TALK
PAGE) 16:48, 10 April 2018 (UTC)
@Tom.Reding: It just occured to me that I was doing it the hard way -- the more strightforward way would simply be to access it via the API (e.g. https://www.wikidata.org/w/api.php?action=wbgetclaims&entity=Q43372357&property=P566). --Ahecht (TALK
PAGE) 17:13, 10 April 2018 (UTC)
@Tom.Reding: It looks like your basionyms code isn't using Module:ResolveEntityId to check whether or not the Wikidata ID exists, breaking the error-detection code (it is now producing the generic "The ID "Q0" is unknown to the system. Please use a valid entity ID." message, which doesn't do the categorization). --Ahecht (TALK
PAGE) 17:05, 16 April 2018 (UTC)
Ahecht,  done for the basionym code. That error text still shows up in testcases though, and has since before I started playing with the module. Do you want to take care of that?   ~ Tom.Reding (talk ⋅dgaf)  17:34, 16 April 2018 (UTC)
@Tom.Reding: done here. --Ahecht (TALK
PAGE) 18:07, 16 April 2018 (UTC)

Linking from the 'wrong' Wikidata item

@Tom.Reding: the basionym addition works well in the cases I've looked at, provided our article is linked from the synonym item on Wikidata. However, this can then lose the interlanguage links if other wikipedias are mostly using the basionym as their article title. Consider Aloidendron dichotomum for example. The taxonbar is specified as {{Taxonbar|from=Q42729505}}, which correctly also displays the basionym, Aloe dichotoma (Q161263). But it only did this after I moved the link to our article from Aloe dichotoma (Q161263) to Aloidendron dichotomum (Q42729505), thereby losing all the interlanguage links. At Aloidendron eminens, where the basionym Aloe eminens (Q138181) has the link to our article, I had to add |from2=Q138181 manually to get the taxonbar to display both the now correct name we use and the basionym still used by most other (out-of-date) wikipedias. Is this due to some test that can be fixed? Are you only looking for the basionym in the Wikidata item that has the link to the article? Peter coxhead (talk) 13:10, 10 April 2018 (UTC)

Peter coxhead, yes, for simplicity and as a 1st iteration, I chose to only look for the basionym on the WD item that is linked to the page, but this can be expanded. What logic would you suggest? Perhaps iterate through all of the |from#= params until I found the first basionym? I'd only be worried about running too many 'expensive' queries, but we definitely still have some headroom before that limit is reached.   ~ Tom.Reding (talk ⋅dgaf)  13:23, 10 April 2018 (UTC)
@Tom.Reding: it's tricky, because yet again we are trying to compensate for the one of the deficiencies of Wikidata, namely that it insists on all language wikipedias being linked from the same Wikidata item, regardless of the taxon name they are using. The best long term solution is for Wikidata to fix this. In the interim, we have two options, and I'm not sure which is the best:
  1. Always link our article from the Wikidata item with same value for the taxon name, and accept that sometimes we'll lose some interlanguage links (which I'm not sure that many readers use anyway). In this case, you don't need to do anything.
  2. Accept that sometimes we have to link our article from a Wikidata item with a different value for taxon name in order to keep the interlanguage links. Then I think the code should iterate through the from parameters until it finds one with a basionym. (I also think that the taxonbar should then display the items strictly in the order given by the from parameters, rather than moving to the top the one which has the link to the article.)
Personally, I'm happy with (1), and think we should continue to press Wikidata to fix the resulting problem. I'm not sure what the consensus here is, though. Peter coxhead (talk) 13:41, 10 April 2018 (UTC)

@Tom.Reding: the basionym is now disappearing. See Corybas globulus for example. It should make no difference whether the second from is specified, but now it does. An error introduced in recent edits? Peter coxhead (talk) 19:54, 16 April 2018 (UTC)

Yes. Ahecht, the last edit to the live module caused the basionyms to disappear. I'll start looking into it, but it'll definitely take me longer to figure it out! (short of undoing, anyway)   ~ Tom.Reding (talk ⋅dgaf)  20:40, 16 April 2018 (UTC)
 Fixed!   ~ Tom.Reding (talk ⋅dgaf)  20:50, 16 April 2018 (UTC)

Extra tracking category

I think it would be useful to have separate tracking categories for taxonbars that actually have manually entered QIDs and those that automatically pick up a QID via a basionym link in Wikidata, rather than put both in Category:Taxonbar templates using multiple Wikidata items. Peter coxhead (talk) 19:03, 23 April 2018 (UTC)

Peter coxhead, I agree. I was thinking about this too, but thought it might've been just me. I think I'll remove Category:Taxonbar templates using multiple Wikidata items altogether and split its contents into Category:Taxonbar templates using multiple manual Wikidata items & Category:Taxonbar templates with automatically added basionyms.   ~ Tom.Reding (talk ⋅dgaf)  20:22, 23 April 2018 (UTC)
 Done! Diffusion in progress.   ~ Tom.Reding (talk ⋅dgaf)  22:45, 23 April 2018 (UTC)

Removing "templates" from all taxonbar category names

While on the subject of category structure, I've been thinking about removing the word "templates" from all of the categories to shorten them, and as it seems a bit redundant. I originally added "templates" to roughly match the preexisting Category:Taxobox cleanup tree, but even it is inconsistent. Also, category names listed under the related Module:Authority control#Tracking categories aren't that explicit either. All this I noticed after the current Category:Taxonbar cleanup structure was in place.

If no resistance to this after a week or so, I think I'll migrate the whole taxonbar tree to non-"template" category names while leaving redirects from the older, longer names.   ~ Tom.Reding (talk ⋅dgaf)  20:28, 23 April 2018 (UTC)

Proposed changes are ready in the sandbox, broken down into 3 discrete steps for maximum KISS-ness.   ~ Tom.Reding (talk ⋅dgaf)  15:07, 24 April 2018 (UTC)
Just to note that I think this is a very sensible change and in line with other cleanup tracking categories (e.g. those for taxoboxes). Peter coxhead (talk) 16:00, 24 April 2018 (UTC)
Due to other pending improvements (here & below), and that this doesn't seem controversial, I'll step implementation up to today/tmrw.   ~ Tom.Reding (talk ⋅dgaf)  13:45, 25 April 2018 (UTC)
 Done! Will null edit the entire tree to force migration in < 12 hrs (esp since there're other cat discussions going on).   ~ Tom.Reding (talk ⋅dgaf)  14:30, 26 April 2018 (UTC)

Monotypic genera

Articles on monotypic genera cover both the genus and the sole species. Hence they should always link to at least two Wikidata items: one for the genus and one for the species. So all articles on monotypic genera should be in Category:Taxonbars using multiple manual Wikidata items, since at present the 'missing' Wikidata item has to be added manually. However, for monotypic plant genera alone, this Petscan shows over 2,200 articles in Category:Monotypic plant genera but not in Category:Taxonbars using multiple manual Wikidata items.

Is there any easy way to add the missing Wikidata item automatically? If so, I think it should be implemented. Peter coxhead (talk) 16:31, 24 April 2018 (UTC)

Peter coxhead, I think the first (or a parallel) step would be to apply instances of monotypic taxon (Q310890) to all appropriate pages under Category:Monotypic taxa - the completion % seem low, and I'm having trouble even finding an example... Perhaps we can find a WD bot to assist? Then, monotypic species items can definitely have their genus's QID automatically appended to the taxonbar (if not already specified via |from2=, etc.). I'm not sure how hard/easy it will be to go from genus to species, and that may have to be done by hand (looking at some properly constructed examples would help make that determination). After the automated additions to the taxonbar are considered, the monotypic pages with only 1 taxonbar row can then be placed into an error tracking cat like Category:Taxonbars of monotypic taxa using only 1 Wikidata item, and successful automatic additions into a non-error cat like Category:Taxonbars with automatically added monotypic taxa.   ~ Tom.Reding (talk ⋅dgaf)  18:25, 24 April 2018 (UTC)
Peter coxhead, appending a monotypic species' genus to the taxonbar is now working in the sandbox and testcases. I'm not sure how to find a monotypic genus' species item via WD though - could you find a properly constructed example to work from? Perhaps there's an existing property that can/is utilized, or one might have to be created?   ~ Tom.Reding (talk ⋅dgaf)  23:20, 27 April 2018 (UTC)
@Tom.Reding: well, I did ask above is there any easy way to add the missing Wikidata item automatically?, and the answer seems to be "only one way – adding the genus to the species, and even then only when the Wikidata genus item is marked as monotypic", which seems to be quite rare. I'm sorry, I don't know enough about the Wikidata API to know whether it's possible to efficiently search for the sole species of a monotypic genus. I think it's not worth spending too long on it if it's difficult or inefficient. Peter coxhead (talk) 06:24, 28 April 2018 (UTC)
Peter coxhead, that's ok. Perhaps this is worthy of going under the longer-term 'module editing to-do list'? (there really should be a property/statement that can be used to specify monotypic species items...) In the meantime, at least there's a way for auto-adding the genus, and the error tracking cat above can be gone through to mark genera as monotypic; still useful. Since we won't be going the other way anytime soon, I think it would be better to use the name Category:Taxonbars with automatically added monotypic genera instead of my original suggestion ('taxa'). If/when the other way is found/created, either a species cat can be created or they can both be lumped into 'taxa', tbd. Regardless of how many types of broken monotypic taxa pathways there are (there are families with only 1 genus?), leaving the Category:Taxonbars of monotypic taxa using only 1 Wikidata name as-is seems good, as it will want to be cleared if populated, so splitting it up seems unnecessary. If you see a good example of genus->species in the wild, let me know.   ~ Tom.Reding (talk ⋅dgaf)  12:40, 28 April 2018 (UTC)
Scratch the part about Category:Taxonbars of monotypic taxa using only 1 Wikidata item, as the name is vague (a problematic page could circumvent this cat by using a basionym from, for example), so the name Category:Taxonbars of monotypic species missing genera would be much more rigorous & useful.   ~ Tom.Reding (talk ⋅dgaf)  13:28, 28 April 2018 (UTC)
Monotypic genus redirecting to the species? There are tons of them in Category:Monotypic fish genera (this is contrary to practice for other groups). Euryale (plant) is a case where the monotypic genus SHOULD redirect to the species; using the binomial as natural disambiguation when the genus name is ambiguous with another topic (if needed, I can provide numerous other examples like this). Plantdrew (talk) 14:51, 28 April 2018 (UTC)
Plantdrew, thanks, that did help in finding candidates. Take Bifax lacinia (Q2920017) & Bifax (Q2182201) for example. The problem is - how does one find, in an automated way, Bifax lacinia (Q2920017) from the Bifax (Q2182201) WD item? Finding the genus from the species is easy, via parent taxon (P171), so I'm looking for a WD property like "child monotypic taxon" (as a preliminary name; "child taxon" would be too broad a proposal), which doesn't seem to exist, to link the monotypic parent to its only child. Would that be worth creating?   ~ Tom.Reding (talk ⋅dgaf)  17:18, 28 April 2018 (UTC)
Can you do a search by incoming links? The only link to Bifax (Q2182201) is from Bifax lacinia (Q2920017), and I'd guess most monotypic genus items only have a link from the species item. But your search skills are stronger than mine, so I guess you've already thought about that approach and rejected it as infeasible. Plantdrew (talk) 23:59, 30 April 2018 (UTC)
I do wish I could do that from the module (like I can locally via AWB). I think I'll put in a property request soon, partly out of utility, partly out of curiosity.   ~ Tom.Reding (talk ⋅dgaf)  11:55, 1 May 2018 (UTC)

See d:Wikidata:Property proposal/child monotypic taxon.   ~ Tom.Reding (talk ⋅dgaf)  14:30, 1 May 2018 (UTC)

LPSN ID

The LPSN URL is in the form http://www.straininfo.net/taxa/379666/browser/euzeby (example for Methylophaga muralis). I'm pretty sure the unique ID is 379666, but Taxonbar displays the ID as "euzeby". The link in the Taxonbar resolves correctly, but I don't think it should be displaying "euzeby". Plantdrew (talk) 20:50, 4 May 2018 (UTC)

Plantdrew, I found Heliobacteria, which also displays an LPSN URL, and the module treats it similarly; that is, it uses the text after the last "/" in the URL as the taxonbar's display text. I could make the module display the # for LPSNs, as long as there is only 1 instance of digits-only between "/" in the URL, otherwise reverting to its normal behavior. Would that be useful?   ~ Tom.Reding (talk ⋅dgaf)  22:38, 4 May 2018 (UTC)
@Plantdrew and Tom.Reding: The module is a bit naive when it comes to summarizing identifiers that are URLs. Technically, the entire URL should be the identifier, but that would take up too much room, so it just takes everything after the final "/". However, at least in this case, I was able to change the LPSN URL to use the more standard form http://www.bacterio.net/methylophaga.html#muralis, which not only matches the examples for wikidata:Property:P1991, but should also display more sensibly. --Ahecht (TALK
PAGE) 02:31, 5 May 2018 (UTC)
Aww, I was looking forward to coding that...   ~ Tom.Reding (talk ⋅dgaf)  03:50, 5 May 2018 (UTC)

Template-protected edit request on 31 May 2018

Could any one add the wikidata properties of Amphibiaweb (P5036) and Tree of Life (P5221) in the module to show links for the authority control? Mr. Fulano (talk) 23:15, 31 May 2018 (UTC)

I'll try to do this tonight, but if not I likely won't have time until after the weekend (in case someone else wants to at that point).   ~ Tom.Reding (talk ⋅dgaf)  23:26, 31 May 2018 (UTC)
 Done.   ~ Tom.Reding (talk ⋅dgaf)  02:12, 1 June 2018 (UTC)

See Wikipedia:Village pump (policy)/Archive_142#Solve legal uncertainty of Wikidata and the further discussions linked there. I've always been curious over the propriety of what seems to have been bot-based importation of data from taxonomic databases; it seems that it may not have been legal. It certainly puts a question mark on directly using any but the most trivial material from WikiData. Peter coxhead (talk) 12:31, 8 May 2018 (UTC)

This template isn't importing data from taxonomic databases, it's just linking to said databases. --Ahecht (TALK
PAGE) 21:55, 8 May 2018 (UTC)
That's not the issue. The issue is whether Wikidata improperly imported data from taxonomic databases to set up parts of itself. So when we link to a Q id, we may be linking to an arrangement of data that Wikidata should not have. Here, we can use information from a copyright taxonomic database, provided we reference it. What it's generally agreed that we can't do is to use an API to extract all the data from that database and use it to set up, say, our taxonomy templates, without any references, because the organization and arrangement of data is covered by copyright (although the law varies from country to country). But that's what seems to have been happening at Wikidata. Peter coxhead (talk) 07:17, 9 May 2018 (UTC)
It'd be good to get a tl;dr of the phabricator discussion when it dies down.   ~ Tom.Reding (talk ⋅dgaf)  11:20, 1 June 2018 (UTC)

Linking to Wikidata in this template

Editors of this template may be interested in WP:VPPRO#How to/should we add a Wikidata item link to Authority control. Please considering providing comment there. --Izno (talk) 13:42, 6 June 2018 (UTC)

Property maintenance required

While making a master properties list and comparing the 2 property lists available (i.e. here and on WD), I found these missing from our /doc & Module:Taxonbar/conf:

  1.   P2752 - New Zealand Organisms RegisterEnglish; all-taxa in NZ
  2.   P3420 - CalfloraEnglish; California wild plants/weeds only
  3.   P3606 - BOLD Systems taxonEnglish; worldwide? DNA based!
  4.   P4194 - CNPSCalifornia rare/endangered plants
  5.   P4301 - PfaFEnglish; edible/'useful' plants; worldwide
  6. (useful above; not-so-useful below)
  7.   P4526 - ABA birdEnglish lang, but not linkable
  8.   P1939 - DyntaxaSwedish lang
  9.   P2794 - Index HepaticarumFrench lang
  10.   P3088 - Catalogue of Life in TaiwanTaiwanese lang
  11.   P3186 - TAXREFFrench lang
  12.   P3322 - VlinderstichtingDutch lang
  13.   P4125 - TitanFrench lang
  14.   P4311 - FOIH taxonDutch lang

and these in our /doc are missing from WD (AWB's list comparer is awesome):

  1.   P2946 - BacDive
  2.   P3060 - ButMoth
  3.   P3101 - FloraBase
  4.   P3100 - Flora of Australia
  5.   P3099 - Internet Bird Collection species
  6.   P4122 - PalDat plant
  7.   P3102 - Plantarium
  8.   P3591 - WCSPF

The first one I happened to come across, P3186, TAXREF, I couldn't find a good link for, except possibly National Museum of Natural History (France), but there's no mention of TAXREF there. Anyway, so instead of mucking things up, I'll just leave this here in the hands of more capable editors...   ~ Tom.Reding (talk ⋅dgaf)  15:57, 28 February 2018 (UTC)

I'm inclined not to include links to non-English language databases on enwiki. Maybe if there some compelling language-independent information, but that can be discussed on a case by case basis. TAXREF does have some photos and maps, but I question the value of a map that shows that alpine salamanders are absent from Clipperton Island, Reunion and New Caledonia (and all other French territories).
And language aside, I'm a little leery of including all-taxa governmental databases. I'd give ITIS a pass since it was probably the best all-taxa database when Wikipedia started up, and was an important source in the early history of Wikipedia. Governmental databases corresponding to biogeographically significant areas (Australia, Madagascar) might be a different story. Plantdrew (talk) 18:09, 1 March 2018 (UTC)

Shortlist vetting

Plantdrew, based on your criteria I went through each of the 13 at the top and narrowed the list down to 5 English language dbs, only 1 of which is intended to be all-taxa (New Zealand, so worth a check imo). Honorable mention goes to ABA bird, but Wikidata's property example links don't work, so that needs to get fixed before considering inclusion. I've grouped the 5 and linked to the 'about' page of each, with a short description. Please let me know which are acceptable, if any.   ~ Tom.Reding (talk ⋅dgaf)  15:57, 10 April 2018 (UTC)

I think the 5 you've highlighted are worthwhile additions. CalFlora frequently shows up as an external link in relevant articles, so I'd really like to see that added. New Zealand is a biogeographically significant region; NZOR is a great examples of a "good" all-taxa governmental database. Plantdrew (talk) 16:41, 10 April 2018 (UTC)
 Done. By my count (had do repeat this query b/c it's not clear how to 'OR'/'UNION' multiple property counts...) up to ~101,000 IDs have now been added to en.wiki! Assuming, of course, that all of those QIDs have a {{Taxonbar}}, and most of the QIDs that point to an en.wiki page should now, thanks to various efforts. Category:Taxonbar pages without Wikidata taxon IDs (0) hasn't really budged though from 18,861 from ~when I started, unfortunately. The breakdown for WD property usage I got was: BOLD:16, Calflora:8903, CNPS:3601, NZOR:86,181, PfaF:2004.   ~ Tom.Reding (talk ⋅dgaf)  18:13, 11 April 2018 (UTC)
Just found how to count all "instance of: taxon"s on WD - 2,424,089. So our 360k is a measly 15%!   ~ Tom.Reding (talk ⋅dgaf)  21:41, 11 April 2018 (UTC)
Yep, it's the Cebuano, Swedish, and Waray Wikipedias that are driving Wikidata's coverage of taxa, not en.wiki or Wikispecies. Charts at d:Wikidata:Statistics/Wikipedia may be of interest. Plantdrew (talk) 21:53, 11 April 2018 (UTC)

AntWeb

@Tom.Reding: pointed me here to make the suggestion of adding AntWeb.org to the property list, as its the most comprehensive database at the moment for Formicidae, and a Creative commons licenced source for many of the ant species images in en.wiki and commmons (eg those on Linguamyrmex.--Kevmin § 00:05, 3 April 2018 (UTC)

Does AntWeb have a unique identifier for records that is not just the taxon name? I'm not seeing one. If the taxon name is the identifier, that suggests a different approach to adding AntWeb support to taxonbars (especially so if AntWeb is being added locally without a property on Wikidata). Plantdrew (talk) 03:59, 3 April 2018 (UTC)
It's disappointing that the consensus at Wikidata was not to handle the fact that databases have entries unless they use a unique id. Thus because Plants of the World Online uses the IPNI id, the Wikidata item won't show that POWO has an entry, whereas I would like to see a flag saying that it does. The same will apply to AntWeb as it doesn't seem to use a unique id. This means that we have to manually add these databases to taxonbars. Sigh... Peter coxhead (talk) 07:46, 3 April 2018 (UTC)
I don't think that was the consensus. Last time I looked only a couple of people took that view and many more supported the more logical and user friendly approach of treating all databases the same way. The disappointment is that the consensus was ignored.   Jts1882 | talk  09:24, 3 April 2018 (UTC)
@Jts1882: I was judging 'consensus' by action, but yes, you're right that most of the comments were in favour of the view we here hold. Perhaps we should try again? A major problem seems to be that there seems to be no tradition at Wikidata of properly closing of discussions, whether by admins or others, and the few regular editors interested in taxonomy over there seem to ignore whatever they don't like. Peter coxhead (talk) 11:21, 3 April 2018 (UTC)
Kevmin et al., given the recent success of POWO, perhaps a property proposal can be made for AntWeb? Not sure how to do that, but reaching out to those involved on Plants of the World Online ID (P5037) or this recent proposal for IRMNG might speed things up.   ~ Tom.Reding (talk ⋅dgaf)  21:41, 11 April 2018 (UTC)
 Done. Parameter |antweb= manually added to the template. The parameter must be manually added to each page for now, until a Wikidata taxon ID property is created.   ~ Tom.Reding (talk ⋅dgaf)  12:08, 20 April 2018 (UTC)
Awesome, how would one add the parameter to say Zatania electra--Kevmin § 22:50, 20 April 2018 (UTC)
Kevmin -  done. I had to allow spaces in |antweb= values.   ~ Tom.Reding (talk ⋅dgaf)  15:19, 21 April 2018 (UTC)
Tom.Reding Thanks, that works perfect--Kevmin § 03:29, 22 April 2018 (UTC)
@Kevmin:, there's now a property proposal at Wikidata. Plantdrew (talk) 19:02, 4 June 2018 (UTC)

POWO

When adding this property to a WD item, is it safe to exclude the urn:lsid:ipni.org:names part of POWO, such as on Veronica chamaedrys (Q157343), for all future entries? If so, then we can update Module:Taxonbar/conf using Plants of the World Online ID (P5037)'s current formatter URL http://www.plantsoftheworldonline.org/taxon/$1. There are 133 hard-coded |powo= that need migration to WD. While migrating, would it be useful to double check that the extra 'ipni.org' prefix text isn't necessary, or would that be a waste of time?   ~ Tom.Reding (talk ⋅dgaf)  21:41, 11 April 2018 (UTC)

ABA

ABA bird ID (P4526)'s formatter URL says no value, and gives the instructions No single site has a record for every species, so I'll try adding it and hope nothing weird happens with the non-existent link.   ~ Tom.Reding (talk ⋅dgaf)  15:53, 4 June 2018 (UTC)

7 more properties found @ d:Template:Taxonomy properties

Do we wish to include these as well? I've made 'vetting notes' for each similar to the original 14 above, and 6 of the 7 below look like they meet Plantdrew's original criterion.

  1.   P3240 - NBN System KeyEnglish lang; UK only
  2.   P3746 - Wildflowers of Israel IDHebrew (default) and English (I can make this default) languages; Israel only
  3.   P4567 - BTO five-letter codeEnglish lang; Britain only; not linkable
  4.   P4758 - MONA IDEnglish lang; North America moths only
  5.   P4855 - Phasmida Species File IDEnglish lang; Phasmida worldwide
  6.   P5216 - GONIAT taxon IDEnglish lang; Paleozoic ammonoids worldwide
  7. (useful above; not-so-useful below)
  8.   P4902 - CONABIO IDSpanish lang; not linkable

  ~ Tom.Reding (talk ⋅dgaf)  15:46, 6 June 2018 (UTC)

Boldly added 5; Wildflowers of Israel ID (P3746) needs testing.   ~ Tom.Reding (talk ⋅dgaf)  14:08, 7 June 2018 (UTC)
Now done.   ~ Tom.Reding (talk ⋅dgaf)  16:26, 7 June 2018 (UTC)

Automatic Wikispecies display & spelling out Wikidata instead of Wd

Currently, |wikispecies=<value> is required to display a link to Wikispecies since the association isn't currently automatically drawn from Wikidata. If desired, I can add this to the automatically displayed IDs, to be displayed either:

  1. after Wikidata "Wd: Q1" in the beginning, or
  2. at the very end, or
  3. alphabetically, or
  4. no change, leaving it in 'manual' mode.

I think #1 is best, with the same manual override as the other IDs.

Also, perhaps spelling out "Wikidata" is better than "Wd". "Wikidata" would I think be required if we put Wikispecies next to it.

Thoughts?   ~ Tom.Reding (talk ⋅dgaf)  17:48, 8 June 2018 (UTC)

 Done   ~ Tom.Reding (talk ⋅dgaf)  00:30, 24 June 2018 (UTC)

Problem with PfaF

The module creates a malformed link (wrong URL, wrong link text) if the Plants for a Future id property contains a space. For instance, in Taxus canadensis, [http://www.pfaf.org/user/Plant.aspx?LatinName=Taxus canadensis Taxus canadensis] should be [http://www.pfaf.org/user/Plant.aspx?LatinName=Taxus+canadensis Taxus canadensis]. Before being put in the link, the property needs to have any spaces in it replaced with pluses, string.gsub(PfaF_id, ' ', '+'). (Or it could be URI-encoded with mw.uri.encode(PfaF_id, "QUERY"), though only the space-to-plus thing part is really needed.) — Eru·tuon 05:55, 26 July 2018 (UTC)

@Tom.Reding: Another PfaF example: if you go to Elaeagnus ×ebbingei (Q2585025) and follow the PfaF ID link, it works correctly. However, in the taxonbar at Elaeagnus × submacrophylla, the PfaF ID has been retrieved and/or displayed incorrectly, and the link does not work. Peter coxhead (talk) 22:19, 6 August 2018 (UTC)

@Erutuon and Peter coxhead:  Fixed.   ~ Tom.Reding (talk ⋅dgaf)  14:59, 7 August 2018 (UTC)

Update to taxon italicization code

The code that italicizes a taxon name in a taxon bar has been updated. It should now handle a wider range of 'special cases' correctly, by not italicizing 'connecting terms' like "sect." or "subsp." or the hybrid symbol (see e.g. the taxonbar at Elaeagnus × submacrophylla where previously the × was italicized, although this doesn't show in some fonts).

If you notice any errors or issues in the italicization of taxon names in taxon bars, please leave a message here. Peter coxhead (talk) 19:24, 18 August 2018 (UTC)

Add Tierstimmenarchiv ID (P5397)

This property links to an entry in the Tierstimmenarchive (de), i.e. the Animal Sound Archive of the Naturkundemuseum, through which sound recordings of the taxon are available. It is currently used on about 1k items. -- Daniel Mietchen (talk) 03:19, 19 September 2018 (UTC)

@Daniel Mietchen: this isn't an English-language source, but since only minimal (e.g. in-browser) translation is needed, and the main content is language-independent, and there have not been any objections for almost a week, I'll add it soon if none appear.   ~ Tom.Reding (talk ⋅dgaf)  12:25, 25 September 2018 (UTC)
 Done. Will null edit the 1233 pages to refresh the template.   ~ Tom.Reding (talk ⋅dgaf)  12:11, 26 September 2018 (UTC)
@Tom.Reding: I think it would be better if the parameter name matched the displayed in the taxonbar. TSA instead of tierstimmenarchiv. Just my 2 cents though. Nice to see work progressing on the taxonbar template. Jeanjung212 (talk) 14:05, 26 September 2018 (UTC)
 Done; yes indeed.   ~ Tom.Reding (talk ⋅dgaf)  14:25, 26 September 2018 (UTC)
@Tom.Reding: There is an English version available (example link). -- Daniel Mietchen (talk) 15:50, 26 September 2018 (UTC)
 Done. P5397 and module updated. I'm surprised that wasn't in the original proposal.   ~ Tom.Reding (talk ⋅dgaf)  18:58, 26 September 2018 (UTC)

(newbie here):

This property was recently added to Wikidata and links to the Catalogue of Lepidoptera of Belgium. It is currently in use on 2800+ articles (the goal of the Catalogue is to fully cover the lepidoptera species that occur in the country). That website provide interesting information, such as the per-province distribution, host plants associations and pictures at different life stages.

I think it would be good to add it to the taxon bar. How to proceed? If I'm not mistaken, we should edit the taxonbar/conf page, but this one is (understandably) protected. Thanks! Niconoe (talk) 08:29, 25 September 2018 (UTC)

 Done Plenty of English language on the property example link.   ~ Tom.Reding (talk ⋅dgaf)  18:04, 9 October 2018 (UTC)

Original combination

I just realized that displaying the basionym via P566 only works for plants. The equivalent term under the ICZN is "original combination" and it the equivalent property is D:P:P1403. Could support for original combination display be added? Plantdrew (talk) 19:12, 18 October 2018 (UTC)

Plantdrew, that's certainly doable. Do you think they should be added to their own tracking category separate from Category:Taxonbars with automatically added basionyms‎, i.e. Category:Taxonbars with automatically added original combinations?   ~ Tom.Reding (talk ⋅dgaf)  19:25, 18 October 2018 (UTC)
I don't think botanical terminology and zoological terminology should be mixed, even when the underlying concept is the same, so there should be separate tracking categories (I wouldn't object to a combined tracking category if the name was something different from both the botanical and zoological terms, but I'm coming up blank on a overarching way to describe the concept). Plantdrew (talk) 19:37, 18 October 2018 (UTC)
Ok, I was leaning towards different tracking categories too, because 1) they use different properties, 2) if only for the initial population using the new property, in case there are any property-specific issues (which is also an argument for continued use).   ~ Tom.Reding (talk ⋅dgaf)  20:43, 18 October 2018 (UTC)
 Done   ~ Tom.Reding (talk ⋅dgaf)  00:40, 19 October 2018 (UTC)
Thank you Tom. I guess it will take awhile for the category to fill and the basionym items to show up? I'm a little puzzled that Japanese pygmy woodpecker has the category for automatically added original combination, but isn't displaying the item for the original combination. Plantdrew (talk) 01:03, 19 October 2018 (UTC)
Ah, that's b/c its original combination Picus kizuki (Q28109050) doesn't have any taxon IDs yet.   ~ Tom.Reding (talk ⋅dgaf)  01:24, 19 October 2018 (UTC)
I looked to see if I could add a taxon ID, but the Wikidata items for this species show up the continued confusion over taxon names versus taxa. Yungipicus kizuki (Q27074882) is trying to be a taxon item, with two taxon names, which isn't allowed. There's currently no separate item for the taxon name Dendrocopos kizuki, which there should be. So right now the taxon bar shows a single line with a mixture of entries for two taxon names. Sigh... Peter coxhead (talk) 10:16, 19 October 2018 (UTC)
Pygmy Woodpecker (Q1267075) was the item for Dendrocopos kizuki, but it was recently merged to the item for Yungipicus kizuki by somebody who isn't a regular Wikidata editor (former problematic en.wiki editor now most active on commons). Reversing the merge is going to take some work (need to retarget some site links), but this case isn't a typical example of how Wikidata (and regular Wikidata editors) handles taxa vs. names. Plantdrew (talk) 16:45, 19 October 2018 (UTC)

Could we replace links like:

Wikidata: Q91703

with:

Wikidata: Q91703 (Scholia)

or even:

Wikidata: Q91703 (Scholia; topic)

I'm sure you'll agree that the Scholia links give a richer user experience. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 20 August 2018 (UTC)

Um... The Scholia link assumes that the Wikidata taxonomy it shows is (a) up-to-date and based on a reliable source, which in my experience is far from always the case, and (b) consistent with the taxonomy used here, which again can be problematic. The topic link seems less of an issue, but perhaps rather specialized for our readers? Peter coxhead (talk) 13:41, 20 August 2018 (UTC)
Off-topic perhaps, but if Wikidata editors concentrated on fixing the known and serious problems in relation to taxa (including the failure to model the difference between taxa and taxon names, and the failure to model the actual relationship between language wiki articles, which is not 1:1), it would inspire more confidence in making more use of Wikidata for taxon articles. Peter coxhead (talk) 13:44, 20 August 2018 (UTC)
I think doing such a thing would be misrepresenting Scholia as a taxonomic database compared to the others for those readers that are not discerning enough to realize the data is just generated out of wikidata.Jeanjung212 (talk) 13:48, 20 August 2018 (UTC)
Wouldn't it be more appropriate to have the links at Wikidata. They could be added as identifiers, although I realise that their having the same taxon ID might be a barrier.   Jts1882 | talk  14:12, 20 August 2018 (UTC)
It certainly seems a good idea to make it easy to explore the taxonomy embedded in Wikidata.
Since Wikidata is supposed (as I understand it) to represent data found in reliable databases, it should really show all the alternative taxonomies that are stored in such sources. This would be even more useful to researchers. Peter coxhead (talk) 15:08, 20 August 2018 (UTC)

To clarify: The Scholia link presents the same data as found in Wikidata, by following the existing Wikidata link, and links to/from that, and no more than that, albeit with better data visualisation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 20 August 2018 (UTC)

The taxonomy scheme on Scholia is interesting because you can see the multiple paths (e.g. three classes for C. elegans). This is awkward to follow by accessing the parents on Wikidata, as you need to go backwards to follow a different parents. The Taxobox systems that use Wikidata for their taxonomy (e.g. the Hebrew Wikipedia only track the first parent listed). So it would be useful to have a link to have somewhere.   Jts1882 | talk  16:30, 20 August 2018 (UTC)
This looks like it could be a candidate for adding to the left-hand margin (e.g. near WikiSpecies, Commons, etc.), but idk how/where that would be requested.   ~ Tom.Reding (talk ⋅dgaf)  12:31, 25 September 2018 (UTC)
This won't happen, as it's context sensitive (it's suitable for papers, and their authors, and scientific topics, for example, but not for other subjects). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:41, 20 October 2018 (UTC)
Pigsonthewing, how is that different from, say, Wikispecies, which only exists for a relatively small subset of all articles? If it exists, it's shown; if not, then it's not.   ~ Tom.Reding (talk ⋅dgaf)  15:54, 20 October 2018 (UTC)
Lots of things exist in Wikidata, which are not relevant in the context described above . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:53, 24 October 2018 (UTC)

VicFlora (P5945)

Hoping someone can add VicFlora ID to the taxonbar. (These have been added to many taxa listed in VicFlora, but do not yet appear on the taxonbar. MargaretRDonald (talk) 00:58, 11 October 2018 (UTC) VicFlora ID (P5945) MargaretRDonald (talk) 01:00, 11 October 2018 (UTC)

 Done. The closest wikilink I could find was Royal Botanic Gardens Victoria#Plant science, which is the publisher, but no explicit mention of VicFlora is made in the article. Is there a better link elsewhere, or can the RBGV page be expanded slightly, or should the wikilink be removed?   ~ Tom.Reding (talk ⋅dgaf)  00:49, 20 October 2018 (UTC)
The National Herbarium of Victoria is slightly better as it mentions the online resources and provides a link in the reference. This could also do with expanding, though.   Jts1882 | talk  06:57, 20 October 2018 (UTC)
 Done   ~ Tom.Reding (talk ⋅dgaf)  11:58, 20 October 2018 (UTC)
Thanks, @Tom.Reding:. It's a good link when it's available. Typically has a decent plant description, a photo and a good map....Whereas many of the other links simply attest the taxon's existence! MargaretRDonald (talk) 19:13, 20 October 2018 (UTC)

NT Flora ID (P5953)

Two points:

  • I note that someone appears to have done a global upload for VicFlora ID (P5945) in wikidata, and it would be good to know how this was done, and equally, if someone could do it for the NT Flora ID.
  • It would be good to have it added to the taxonbar, as generally, when available for a plant, it gives a good description (and currently the coverage of northern australia is poor) MargaretRDonald (talk) 21:23, 24 October 2018 (UTC)
Maybe wait on this a bit? It seems that d:P:P5953 is only used on 7 Wikidata items so far. Succu does most of the work on Wikidata related to taxon IDs (although it appears that another user was responsible for adding the VicFlora IDs). Succu was blowing up my watchlist the last few days adding IDs for APNI (d:P:P5984, it would be good to get the APNI ID in the taxonbar (as well as NT Flora ID once it is more widely used). Plantdrew (talk) 21:46, 24 October 2018 (UTC)
 Done, a bit prematurely though. I searched for uses and accidentally found several thousand when I typed the wrong property ID number in. NTFlora is actually still only used on 7 en.wiki pages at the moment, and 17 total. On the other hand, I don't think it's necessarily worth reverting, but I wouldn't contest a rv either.
I could not find a suitable wikilink, so it would be good for more information to be available about the database itself.   ~ Tom.Reding (talk ⋅dgaf)  14:38, 19 November 2018 (UTC)
Thanks for your help on this. NT Flora Homepage indicates what a useful resource it is, covering some 4300 indigenous plants in an area which has not been well-served by wikipedia. I am hoping that someone will help me to get the NT flora IDs into wikidata automatically. Where they exist they give excellent descriptions, maps, aboriginal names... unlike many botanic IDs which merely give the authors. MargaretRDonald (talk) 20:58, 19 November 2018 (UTC) MargaretRDonald (talk) 21:02, 19 November 2018 (UTC)
MargaretRDonald, what I meant was that Wikipedia needs more info on the database itself, not I nor the readers here.
As for populating Wikidata entities with this property, I'll ping Succu so that they can do so if/when they are able.   ~ Tom.Reding (talk ⋅dgaf)  21:27, 19 November 2018 (UTC)

Template-protected edit request on 2 December 2018

Change "ADW" to "AFD" in the following line's piped link: 

	{ 'AFD', '[[Australian Faunal Directory|ADW]]', 6039 },

Monster Iestyn (talk) 19:37, 2 December 2018 (UTC)

 Done.   ~ Tom.Reding (talk ⋅dgaf)  20:16, 2 December 2018 (UTC)

Template-protected edit request on 8 December 2018

Replace 

{ 'GISD', '[[fr:Global Invasive Species Database|GISD]]', 5626 },

to 

{ 'GISD', '[[:fr:Global Invasive Species Database|GISD]]', 5626 },

This is including page in interwiki-links. ‐‐1997kB (talk) 09:41, 8 December 2018 (UTC)

 Done. ~Oshwah~(talk) (contribs) 10:03, 8 December 2018 (UTC)

Interim Register of Marine and Nonmarine Genera

Please link the "IRMNG" label to Interim Register of Marine and Nonmarine Genera. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 10 December 2018 (UTC)

 Done.   ~ Tom.Reding (talk ⋅dgaf)  21:04, 10 December 2018 (UTC)

Catlogue of Life ID?

As far as I can tell, Catalogue of Life (Q38840) has no associated property ID (Catalogue of Life in Taiwan ID (old version) (P3088) is the closest I found). Would there be support for such a property proposal?   ~ Tom.Reding (talk ⋅dgaf)  16:27, 5 January 2019 (UTC)

I think there might not be support. It's not like Succu and Brya are unaware that Catalogue of Life exists; I understand they were kind of cranky about dealing with a large number of Wikidata entries derived from Lsjbot articles on the Swedish Wikipedia that were based on garbage CoL entries (see Wikipedia:Wikipedia Signpost/2015-09-09/News and notes#The Swedish Wikipedia hits one million articles in a rather embarrassing way... for discussion of one problematic Swedish article). I'm not sure why ignoring CoL would be better than creating a property for CoL and using it to explain where some of the garbage taxon items ultimately came from, but I assume Succu has some reasons for not having a CoL property. I guess it might be worth floating a proposal anyway, to get any objections on record, even if a property doesn't end up being created. Plantdrew (talk) 16:45, 5 January 2019 (UTC)
I almost forgot; another possible issue with CoL is that their identifiers may not be stable. I gather they sometimes change data providers for given groups of organisms, and the IDs may change with the provider. And occasional Wikipedia editor Rdmpage pointed out some problems with how CoL handled LSIDs in this 2013 blog post. Plantdrew (talk) 16:56, 5 January 2019 (UTC)
Yep that's what I was afraid of, and figured this might be mostly (save me) common knowledge, since I couldn't find a proper discussion. If it weren't for the unstable IDs, I'd consider a proposal.   ~ Tom.Reding (talk ⋅dgaf) 

PfaF ID

This id should be deleted from the Taxonbar. The site is a charity and while possibly a worthy and useful site does not seem to have the resources to make it an authoritative site. Its entries are incomplete and unreferenced: See e.g., PfaF:Ficus coronata and compare it with the well referenced Ficus coronata English wikipedia article which shows that this species occurs in many Australian states in addition to New South Wales. It may occasionally be useful as a reference but should not generally be used as an authority when other better authorities are available. I would like it deleted since it is incomplete and therefore potentially misleading, as in the case of Ficus coronata. MargaretRDonald (talk) 18:54, 5 January 2019 (UTC)

The citation on that PFaF page you mentioned is "Carolin. R. & Tindale. M. Flora of the Sydney Region Reed. Australia. 1993 ISBN 0730104001." Is that not sufficient? --Nessie (talk) 01:53, 6 January 2019 (UTC)

Constraint to Category:Taxonbar pages without Wikidata taxon IDs

Category:Taxonbar pages without Wikidata taxon IDs was being added to pages where any one of the other |from#= parameters, an automatically added basionym, an automatically added original combination, or the main Wikidata item to the Wikipedia page, was devoid of taxon IDs. Now, the category only applies to the Wikidata item linked to the Wikipedia page. I can recover this lost functionality by creating a separate category (or categories) for ancillary QIDs which are missing taxon IDs, if there's an interest for it.   ~ Tom.Reding (talk ⋅dgaf)  23:12, 6 January 2019 (UTC)

Assuming that part of the reason for the similar Category:Taxonbars on possible non-taxon pages is to make sure Wikidata is correct, I can see the prospective category serving a similar purpose. Though I bet many will be instances of "synonym" or other acceptable items. --Nessie (talk) 00:24, 7 January 2019 (UTC)
Yes, that is the ultimate goal. I think the 2 cases can be generally distinguished by
There are on the order of 1000 that would be placed into the secondary cat.   ~ Tom.Reding (talk ⋅dgaf)  14:59, 7 January 2019 (UTC)
 Done - all previous pages distributed.   ~ Tom.Reding (talk ⋅dgaf)  20:43, 8 January 2019 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Taxonbar/Archive_4&oldid=897163248"