Template talk:Taxonbar

{{Taxonbar}} (edit talk history links # /subpages /doc /doc edit /sbox /sbox diff /test)

'Exists' module misses cases where the taxonbar is commented out

I happened to notice that a page with the taxonbar commented out didn't appear in Category:Taxobox articles missing a taxonbar. Looking at Module:Taxonbar/exists and Module:Template redirect regex, I can see why not. I don't think there's any obvious fix, but this search finds pages where taxonbars have been commented out. Of course, those pages may also have taxonbars that are not commented out.

I have uncommented many examples.[1]

William Avery (talk) 07:42, 11 April 2024 (UTC)

The regex in Module:Taxonbar/exists could be modified to check for the comment, but that might be tricky. A simpler change would be to add a second search. If a taxonbar is found it check to see if it's preceded by a comment (similar to your search). It might be better to have a category for commented out taxonbars. —  Jts1882 | talk  10:34, 11 April 2024 (UTC)

I assume examples like Violet-crowned_hummingbird were commented out because the taxonbar scientific name didn't match the article scientific name. This bird was moved from Amazilia violiceps to Leucolia violiceps by Birdlife/IUCN and to Ramosomyia violiceps by ebird/BOW. It needed changes on Wikidata to work properly. It would be useful to have such cases flagged. —  Jts1882 | talk  10:53, 11 April 2024 (UTC)

I'm trying in Module:Taxonbar/exists/sandbox, but I'm unable to match <!-- for some reason... Can anyone help? See line 17 & 20 there, and Template:Taxonbar/exists/testcases/true#True.   ~ Tom.Reding (talk ⋅dgaf)  14:06, 16 April 2024 (UTC)

Don't you need braces and spaces to check before: local v_cmt_before = '%<%!%-%-%s*%{%{'..v? —  Jts1882 | talk  14:28, 16 April 2024 (UTC)

@Jts1882: not for the current testcase, which has <!--{{Taxonbar}}--> for simplicity, and braces don't need escaping in Lua (since generalized finite quantifiers {n,m} don't exist in this implementation). Regardless, I found the problem. I was using .baseText for the pagename, so the regex was running on Template:Taxonbar/exists/testcases instead of the intended Template:Taxonbar/exists/testcases/true... Shouldn't be a problem to implement now...!   ~ Tom.Reding (talk ⋅dgaf)  14:33, 17 April 2024 (UTC)

@William Avery and Jts1882:  Done! Pages with commented taxonbars should now be processed as if it doesn't exist, and be categorized accordingly.   ~ Tom.Reding (talk ⋅dgaf)  14:54, 17 April 2024 (UTC)

I fiddled about with Mesembrinella aeneiventris to see if it would go into a maintenance category, but I had no luck. William Avery (talk) 09:04, 18 April 2024 (UTC)

@Tom.Reding: I think line 10 needs deleting. —  Jts1882 | talk  11:14, 18 April 2024 (UTC)

 Oops   ~ Tom.Reding (talk ⋅dgaf)  11:19, 18 April 2024 (UTC)

I'm starting to see some of the articles with commented out taxonbars showing up in the missing category now, which I've then been able to update appropriately. Good job! - UtherSRG (talk) 14:25, 18 April 2024 (UTC)

Taxonbar for mobile

This topic has come upon a number of occasions, most recently at WT:Automated_taxobox_system#Automatic links to species, commons, data. Taxonbar uses Navbox and for some reason this is disabled on mobile. Anything using class="navbox" is removed server side, although the templatestyles are still on the page.

Last year I did some experiments on alternative outputs for taxonbar information, bypassing Navbox, and also using taxonbar to output sitelinks. I've restored these options to Module:Taxonbar/sandbox and placed the examples in User:Jts1882/taxonbar. I was trying to work out what works on mobile and what doesn't and surprisingly all the collapsible options worked. More surprisingly the taxonbars worked (I've since seen the taxonbar documentation and testcases show taxonbars on mobile). Navbox is only blocked in mainspace, not template of user space.

Anyway, the reason for this topic is I've created prototype output in Navbox style that works on mobile:

• Mobile compatible taxonbar: {{Taxonbar/sandbox|from=Q11847339|from2=Q593398|format=pseudo-taxonbar}}

Taxon identifiers
Pterorana	Wikidata: Q11847339 Wikispecies: Pterorana ASW: Pterorana CoL: 642TW EoL: 103550 GBIF: 2426818 iNaturalist: 26276 IRMNG: 1289159 ITIS: 661533 NCBI: 685169
Pterorana khare	Wikidata: Q593398 Wikispecies: Pterorana khare AmphibiaWeb: 5068 AoI: 328 ARKive: pterorana-khare ASW: Pterorana-khare CoL: 4Q356 EoL: 1039191 GBIF: 2426819 iNaturalist: 26277 IRMNG: 11425915 ITIS: 665203 IUCN: 58488 NCBI: 877586 Observation.org: 205301 Open Tree of Life: 3618409 uBio: 4801185

• Standard taxonbar for comparison: {{Taxonbar|from=Q11847339|from2=Q593398}}

To test on mobile you can copy the code above and preview it on the Indian_flying_frog page.

I'm uncertain if this should be implemented. There is a reason Navbox is blocked and this might be considered an attempt to bypass a Wikipedia policy. My suspicion is that big nested Navboxes are the problem and a small simple table like the taxonbar doesn't cause the same issues. —  Jts1882 | talk  12:25, 25 April 2024 (UTC)

Looks good! Whom can we ask about the potential policy issue? - UtherSRG (talk) 12:44, 25 April 2024 (UTC)

Not sure.

I've done a little research and found T124168. The main objections are that they use large nested HTML tables, which supposedly don't show so well on mobile, and have large download sizes. My mobile version about uses one table with two columns, so probably isn't the type of Navbox that led to prohibition.

A better solution is to make a <div> based output. A problem here is aligning the left hand column without using a fixed width and getting the floating elements right. I found a neater method using display:grid which I've implemented using templatestyles.

• Mobile compatible taxonbar (using grid and divs): {{Taxonbar/sandbox|from=Q11847339|from2=Q593398|format=grid-taxonbar}}

Taxon identifiers

Pterorana

• Wikidata: Q11847339
• Wikispecies: Pterorana
• ASW: Pterorana
• CoL: 642TW
• EoL: 103550
• GBIF: 2426818
• iNaturalist: 26276
• IRMNG: 1289159
• ITIS: 661533
• NCBI: 685169

Pterorana khare

• Wikidata: Q593398
• Wikispecies: Pterorana khare
• AmphibiaWeb: 5068
• AoI: 328
• ARKive: pterorana-khare
• ASW: Pterorana-khare
• CoL: 4Q356
• EoL: 1039191
• GBIF: 2426819
• iNaturalist: 26277
• IRMNG: 11425915
• ITIS: 665203
• IUCN: 58488
• NCBI: 877586
• Observation.org: 205301
• Open Tree of Life: 3618409
• uBio: 4801185

• Standard taxonbar for comparison: {{Taxonbar|from=Q11847339|from2=Q593398}}

A problem here is backward compatibility. Grid is supported by all browsers, but I don't know for how long. Wikipedia wants everything to remain compatible with the abacus, except for Vector-2022 which is allowed to break everything.

Anyway, I think I've seen enough to think we can convert the taxonbar to a non-navbox solution which can be seen on mobile. —  Jts1882 | talk  16:57, 25 April 2024 (UTC)

"nomenclatural type of" usage being frowned upon

@Jts1882 and Tom.Reding: (or anyone...) I'm being told on my WD talk that our use of nomenclatural type of (Q116044186) is incorrect. I'm not sure whether they are saying we should be using nomenclatural type (Q116538381) or do something else. Can y'all jump in and help straighten this out? - UtherSRG (talk) 16:44, 30 April 2024 (UTC)

@UtherSRG:, while I'm not sure exactly what a inverse property label item (Q65932995) is or how it is to be used, I notice that it is a Wikidata item (Q), not a Wikidata property (P). An inverse relationship that I understand better is natural product of taxon (P1582) and this taxon is source of (P1672); those are both properties. d:User:ChristianKl/Out of scope use of labels shows 196 instances of " nomenclatural type of", and there are 200 pages linked to the item; one is your talk page, one is ChristianKL's Out of scope page, and one taxonomic type (P427). That leaves one taxon page that isn't on the Out of scope page (and is presumably "in scope"?) but I don't know what it is. Of the instances of Q116044186 I've looked at, I haven't found any that weren't added by you.

I'm not sure what you are trying to accomplish. If it's in support of allowing taxonbars to automatically pick up multiple Wikidata items related to monotypy, there is still the problem I mentioned in a now-archived thread of monotypic genera where the type species is a synonym of the only accepted species. That is a rare situation, but it does happen.

monotypic taxon (Q310890) is problematic; whether a taxon is monotypic or not may vary between different taxonomic viewpoints. Wikidata is supposed to represent different taxonomic viewpoints equally.

I'm not sure that it is really feasible to have taxonbars pick up multiple Wikidata items related to monotypy. Plantdrew (talk) 19:18, 30 April 2024 (UTC)

The work I did was in support of existing taxonbar coding, so as to help categorize usage properly, so yes, to determine if the QIDs being provided to the taxonbar are a monotypic pairing. I did so under advisement from Jts1882 (IIRC) when I asked about working to solve some of the issues at Category:Taxonbar cleanup and Category:Taxobox cleanup. If what I'm doing is not the correct solution, what is? And the taxonbar will need its code changed to accomodate. - UtherSRG (talk) 23:57, 30 April 2024 (UTC)

Iirc, I suggested we could use the type species to get the child species for a monotypic genus and Tom.Reding implemented this. Looking at the code, it retrieves taxonomic type (P427) for monotypic genera and checks whether it is monotypic taxon (Q310890) or monotypic fossil taxon (Q47487597), in which case it is accepted. I don't see a use of nomenclatural type of (Q116044186) or nomenclatural type (Q116538381) so I'm confused about what the issue is about. —  Jts1882 | talk  06:51, 1 May 2024 (UTC)

I don't think checking a putative type species for monotypy is the correct approach to test validity. The type doesn't need to be monotypic. I'm not sure what to check for as the taxonomic type (P427) examples include a type specimen. Perhaps check that the item is a taxon name and has the monotypic genus as its parent. —  Jts1882 | talk  08:46, 1 May 2024 (UTC)

No one answered this, but I think checking that monotypic genus has a taxonomic type (P427) that is a taxon name and has a parent matching the monotypic genus will pick up some species of monotypic genera. It won't when there are new combinations. —  Jts1882 | talk  13:35, 3 May 2024 (UTC)

@Tom.Reding: This is my suggestion. —  Jts1882 | talk  14:23, 3 May 2024 (UTC)

Going back to Plantdrew's post above, I agree that we should not be using monotypic taxon (Q310890) to determine whether a taxon is monotypic or not, because of Wikidata's neutrality on taxonomic views. Lumpers, like PoWO for ferns, will have many fewer monotypic taxa than splitters. We have to decide one way or the other for the article title and taxobox, but Wikidata does not and should not. Peter coxhead (talk) 07:07, 1 May 2024 (UTC)

The taxonbar is looking for alternative treatments, so this might not be a problem. —  Jts1882 | talk  08:46, 1 May 2024 (UTC)

This is in regards to how to populate these tracking categories:

• Category:Taxonbars of monotypic genera missing species‎ (4,022 P)
• Category:Taxonbars of monotypic species missing genera‎ (empty)
• Category:Taxonbars with automatically added monotypic genera (empty)
• Category:Taxonbars with automatically added monotypic species‎ (empty)

But perhaps we don't have the right tracking categories. I've been assuming we do, as this was set up for a reason, but I don't know that we do. Given the lopsidedness of the population of the categories, probably we don't. Jts1882 you are correct in your assessment that we aren't using the "nomenclatural" fields on WD... but our discussion was that we needed a method to note both sides of the parent-child monotypic relationship, but then it didn't get implemented, IIRC, even though I'd already been updating WD with it. I don't recall which archived talk page had the discussion, but the past is the past and we should look to the future.

If we don't want to track monotypy, then let's just delete these four categories, remove the code that populates them, and I'll undo the ~200 uses of "nomenclatural type of" on WD that I added.

Assuming, then, that we do want to track "something" about monotypy, what do we do? We need a way to detect a monotypy, and we need to determine if the QIDs we have on hand align with that monotypy. On one hand, we have one or more QIDs listed in the taxonbar. Does the information on Wikidata for these QIDs indicate we have a monotypy, and does the collection of QIDs in the taxonbar include both the parent and child of the monotypy? On the otherhand, we currently have no way to indicate on the taxonbar that we have a monotypy a priori. This may be something we want to address.

To address Peter coxhead's issue directly, while you are correct from an article and taxobox perspective, I don't think that's an issue from a taxonbar point of view. We have to pick a single taxonomy for the article and taxobox, but the taxonbar can list multiple combinations and thus be neutral on taxonomic views. This allows us to fully utilize the array of taxonomies recorded at Wikidata.

Be that as it may, let's continue with the assumption and the given existing tracking categories, and determine the right algorithm to populate them, and what WD fields/properties to use to do this, that doesn't rock the boat on WD's side.

Loop over the QID collection

• If the QID (parent) indicates it is monotypic (monotypic taxon or monotypic fossil taxon) (and if we haven't checked this QID already from the child->parent relationship)
  • If the parent's taxonomic type (child) indicates it is the parent's type (how? subject has role -> nomenclatural type -> parent? Something else/new?)
    • We have a confirmed monotypy parent->child
    • If child is not in our current collection, add category "missing child" (or be bold and add the child to our collection and add category "automatically added child") [A]
• If QID (child) indicates it is the type of some parent (see how? above) (and if we haven't checked this QID already from the parent->child relationship)
  • If the parent indicates is is monotypic (monotypic taxon or monotypic fossil taxon)
    • We have a confirmed monotypy child<-parent
    • If parent is not in our current collection, add category "missing parent" (or be bold and add the child to our collection and add category "automatically added parent") [B]

On the "how" question, if "nomenclatural type of" is not the right way, what can we use? Change it from nomenclatural type of (Q116044186) to nomenclatural type (Q116538381)? Add a new property that is the inverse of taxonomic type (P427)? Something else? I think we need input from someone familiar with the expectations on the WD side like d:User:ChristianKl (and I've let them know we are having this discussion and asked them to take a look here).

If we do want to a priori indicate we have a monotypy, I suggest adding new fields to the taxonbar in some manner like this: |monotypic_parentN=x and |monotypic_childN=x where N is a number (we may have multiple monotypic taxa in one article, so N number of parent/child relationships) and x indicates which fromN field fills this role. For instance: {{Taxonbar|from1=Q123|from2=Q456|monotypic_parent1=1|monotypic_child1=2}} would indicate from1 & from2 form a monotypy, with from1 being the parent and from2 being the child.

Given the above, I would suggest some the following as well:

1. The algorithm above, when detecting a monotypy exists on WD, but we have no a priori indication, add (new) category "missing monotypy fields for monotypic pairing". [C] This may be in addition to a missing parent/child, if we are missing a QID in the taxonbar.
2. The algorithm above, when not detecting a monotypy on WD, but we do have an a priori indication, add (new) category "monotypy needs additional Wikidata item".

Finally, that set of categories I started with? I'm now sure it's not the best set and that we can do better. I don't think we care specifically about monotypic genera, but that we care about monotypic taxa in general. (Yes, pun intended with "specifically" and "in general".) Why would we want to track monotypic genera, and not other monotypic taxa? If we use the various changes I suggest in this post, I think the following is a better set of tracking categories:

• Category:Taxonbars of monotypic parent missing child‎ or Category:Taxonbars with automatically added monotypic child (one or the other from [A])
• Category:Taxonbars of monotypic child missing parent‎ or Category:Taxonbars with automatically added child of monotypic taxon (one or the other from [B])
• Category:Taxonbars missing monotypy fields (from [C])
• Category:Taxonbars pages requiring monotypic Wikidata item (from [D])

Looking at Category:Taxonbar cleanup and how the subcategories are sorted, I would say [A] and [B] would be "T" types, [C] is "M" type, and [D] is "E" type. I also think we need to review the remaining subcategories of Category:Taxonbar cleanup with regard to whether or not we need them, and if they are properly sorted, but that's a topic for another discussion. - UtherSRG (talk) 12:09, 1 May 2024 (UTC)

The biggest hurdle is going from parent -> child in Wikidata. If taxonomic type (P427) is not appropriate for this purpose, then we should try to resurrect d:Wikidata:Property proposal/child monotypic taxon from 6 years ago. There's obviously a need for it, or something like it. If that can't/won't be done, then we should probably abandon this effort for finding/tracking monotypes. I think it's in the best interests of Wikidata and all the Wikipedias that such a property exists, and it would be silly/lazy to not have it.   ~ Tom.Reding (talk ⋅dgaf)  14:24, 1 May 2024 (UTC)

taxonomic type (P427) is not appropriate for this purpose. For Psilurus, the type is Psilurus nardoides, which is a synonym of the only accepted species, Psilurus incurvus. Another issue is that as per the ICZN: "Recommendation 67B. Citation of type species. The name of a type species should be cited by its original binomen" (botanists also do this). The ICZN gives the example of Astacus marinus as the type of Homarus, which is what the Wikipedia article shows. But Wikipedia is inconsistent in following that practice. I haven't paid enough attention to Wikidata's type species statements to know if Wikidata is consistent, but I suspect it is not. The type being a synonym is an uncommon situation. The type being an original binomen is more common. Plantdrew (talk) 16:33, 1 May 2024 (UTC)

Hrm. This is a very good point. Couple that with Tom's point above regarding the previous attempt at a "child monotypic taxon" property, and I think we need to start with a fresh new pair of properties, though resurrecting the proposal and adding a "parent monotypic taxon" property might be possible. Hrm.... - UtherSRG (talk) 16:52, 1 May 2024 (UTC)

This isn't the first time I've raised an issue, we have a bunch of discussion, and then nothing happens, and I move on to other work because things were left hanging. I don't want to repeat that. So... are we going to do anything here? - UtherSRG (talk) 13:09, 3 May 2024 (UTC)

If we don't want to move forward with finding a way to track monotypy, then let's remove that tracking from the taxonbar and remove those four categories. - UtherSRG (talk) 13:11, 3 May 2024 (UTC)

I've bumped a suggestion I made earlier which got ignore (or dismissed as rubbish). Think that could pick up some species of monotypic genera. —  Jts1882 | talk  13:37, 3 May 2024 (UTC)

Plantdrew nixed that, because the taxonomic type of a species may not belong to the genus, if the species is being moved from one genus to the new genus. (Though I'm betting more often than not the new combination is used in the P427 field when it should not be.) - UtherSRG (talk) 14:22, 3 May 2024 (UTC)

Which suggestion is that, and how does it compare to the potential "child monotypic taxon" + "parent monotypic taxon" Wikidata properties? I admit I haven't been completely following all the discussions...   ~ Tom.Reding (talk ⋅dgaf) 

(You used three tildes... so manually replying) He replied quite a bit above to suggest using P427 in a different manner. checking that monotypic genus has a taxonomic type (P427) that is a taxon name and has a parent matching the monotypic genus will pick up some species of monotypic genera. It won't when there are new combinations. - UtherSRG (talk) 14:23, 3 May 2024 (UTC)

Yes, it will pick up some, but not sufficient to pick up all. This should only pick up monotypys where a newly described species and its genus are described at the same time, not when a new genus is described from an old species. We need a solution for both kinds. - UtherSRG (talk) 14:25, 3 May 2024 (UTC)

My test for the parent taxon would ensure the genus matches. —  Jts1882 | talk  14:53, 3 May 2024 (UTC)

Are we all in agreement then that d:Wikidata:Property proposal/child monotypic taxon should be resubmitted, along with a to-be-drafted d:Wikidata:Property proposal/parent monotypic taxon? I'd like to see a strong show of support here before they're re/submitted.   ~ Tom.Reding (talk ⋅dgaf)  14:29, 3 May 2024 (UTC)

For taxa that are both a child and a parent in a monotypy (so for example a family that has a single species), would both of these properties be used? - UtherSRG (talk) 14:31, 3 May 2024 (UTC)

Yes, the genus would/should have both, which would make it very easy to go up/down the monotype line.   ~ Tom.Reding (talk ⋅dgaf)  14:39, 3 May 2024 (UTC)

Cool. Then yes, I'm in support of resubmitting and having the parent property drafted. They should be submitted together so that they can be discussed as a pair. I think we could then argue that both monotypic taxon (Q310890) and the fossil equivalent can be mothballed as no longer relevant and all uses replaced with just plain "taxon". UtherSRG (talk) 14:45, 3 May 2024 (UTC)

monotypic taxon (Q310890) is not a property, so its functionality is different, and still useful, e.g. instance of (P31) -> monotypic taxon (Q310890). Its description would be amended to allow it to be used on parents or children, as opposed to only on parents.   ~ Tom.Reding (talk ⋅dgaf)  15:02, 3 May 2024 (UTC)

I was using it in this manner and was harshly squashed for doing do. They will not accept that. - UtherSRG (talk) 16:06, 3 May 2024 (UTC)

Can you link to that/those discussion/s? There are 10,749 instance of (P31) -> monotypic taxon (Q310890), so unless you placed most of those, that's definitely one of the valid use-cases. Regardless, this is something to discuss after the proposals.   ~ Tom.Reding (talk ⋅dgaf)  15:08, 4 May 2024 (UTC)

I was squashed for using monotypic taxon (Q310890) on species of monotypic parents, first on the talk of an item, then at their AN board. - UtherSRG (talk) 17:23, 4 May 2024 (UTC)

Let me state what I understand is being proposed. The child monotypic taxon property would be added to monotypic taxon items and specify the single child taxon (i.e. it is a "child taxon of monotypic taxon property"). The parent monotypic taxon property would be added to the single child taxon item to indicate that the parent is monotypic. Perhaps it should be designed to be a qualifier of parent taxon, i.e. an "is monotypic property". Alternatively a parent taxon could be qualified with instance of (P31) with monotypic taxon (Q310890) using existing properties (if this is allowed). —  Jts1882 | talk  16:10, 3 May 2024 (UTC)

"Parent monotypic taxon" & "child monotypic taxon" properties in this case mean "has parent monotypic taxon" & "has child monotypic taxon" (as opposed to "IS parent/child monotypic taxon"), in keeping with the existing parent taxon (P171) property usage.

I'll use Uther's example since that covers all permutations, where a monotypic family has a singular species. The family item would have the "child monotypic taxon" property pointing to the genus. The genus would have "parent monotypic taxon" pointing back to the family, and have "child monotypic taxon" pointing to the species. And the species would have "parent monotypic taxon" pointing back to the genus.   ~ Tom.Reding (talk ⋅dgaf)  15:08, 4 May 2024 (UTC)