Jump to content

Template talk:Taxonbar/Archive 7

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 5Archive 6Archive 7Archive 8Archive 9

Deprecated IDs being displayed

Earlier today I added a taxonbar to the article Dejeania and noticed that the magnificent beast in the taxobox was definitely a fly, but the taxonbar was showing a ButMoth id. Investigating, I discovered that it was simply a case of a wrongly applied id (The ButMoth id given is for a junior homonym: Dejeania Oberthür, 1896). I decided that the best thing to do was to deprecate the value and add a qualifier to say why it was wrong. This reduces the likelihood of a user or bot putting it back again. I was then surprised to discover that the value didn't disappear from the taxonbar. Hopefully, we can agree that deprecated values shouldn't appear, whatever the rights and wrongs of my using deprecation in this case. There is a relevant discussion in progress at d:Wikidata:Requests for comment/Handling of stored IDs after they've been deleted or redirected in the external database.

Looking at the function getIdFromWikidata, I see that no checks are made on "rank", and I suspect that rather than iterating over item.claims[property] it should be using item:getBestStatements(property).

Disclaimer: I have never actually written a single line of Lua. William Avery (talk) 15:54, 1 November 2021 (UTC)

My understanding (a big caveat here) is that item:getBestStatements(property) should handle the checking of deprecated properties. Changes at Wikidata are often subject to a substantial delay before they appear. Null edits and rain dances sometimes help. —  Jts1882 | talk  16:24, 1 November 2021 (UTC)
However, item:getBestStatements(property) might still choose it if there are no alternatives (i.e. best choice available). One option is to set |butmoth=no in the taxonbar, which will suppress the display. I've added this at Dejeania. —  Jts1882 | talk  16:32, 1 November 2021 (UTC)
The documentation of getBestStatements (here) is quite explicit that 'It will never return "deprecated" statements'. Of all my various rain dances (which can be seen at https://www.wikidata.org/w/index.php?title=Q15633381&action=history) the only one that worked was actually removing the value. William Avery (talk) 18:38, 1 November 2021 (UTC)
The documentation is clear enough, as you say, and correct. The code for taxonbar uses item:getBestStatements(property) to get information about the property (e.g. formatterURL for ButMoth ID (P3060)) but not for getting the value of the property from the taxon item (e.g. P3060=8150.1 for Dejeania (Q15633381)). The current code assumes any value is valid. I did a test and item:getBestStatements(property) doesn't pick up the deprecated value for P3060[butmoth], whereas using item:getAllStatements(property) does pick up the deprecated value. So it should be possible to add a check so taxonbar rejects deprecated values. Working out exactly where is another matter. —  Jts1882 | talk  12:07, 2 November 2021 (UTC)
I think I have found the right place. The changes are made in the sandbox: Module:Taxonbar/sandbox.

I found the parameter names a bit confusing. WikidataID is the value of the ID for the external database, fetched from Wikidata, as opposed to the ID entered manually using the taxonbar parameters. —  Jts1882 | talk  16:16, 2 November 2021 (UTC)

Thanks. That is where I thought the change should go, but I have no idea how these modules are tested, or how the movement of code from test to live is managed. I have ascertained that there are rather a lot of ButMoth IDs where the source site says that a given ID for a genus applies to a "junior homonym", but the ID has been stuck on an item for the corresponding "available name" in Wikidata. William Avery (talk) 19:33, 7 November 2021 (UTC)
I've updated the live module. I checked through all the testcases and the one change was an EoL that was indeed deprecated.

Links to the Amphibian Species of the World (ASW) do not work. Forward slashes in the taxon ID are encoded as "%2F" in the URL, which is not recognized by the server. For example on this page: Antilles coqui. Cheers, Micromesistius (talk) 13:48, 11 November 2021 (UTC)

This seems to be related to a recent change to URL encoding I made following a suggestion by Lockal in this discussion about Reptile Database links. It seemed to pass all the {{Taxonbar/testcases}} and all links I tried worked. However, there always seems to be exceptions. I'll look into this to see if there is a general solution. Otherwise I'll exclude ASW6 from the URL encoding. —  Jts1882 | talk  15:41, 11 November 2021 (UTC)
@Jts1882: huh nice catch! Here is an exact reason why it happens - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/664820/3/lib/includes/PropertyInfoSnakUrlExpander.php#50 . So to completely replicate Wikidata behaviour, after urlencoding one should just replace '%2F' with '/' back. --Lockal (talk) 19:55, 11 November 2021 (UTC)
Change made to not encode backslash. @Micromesistius: It should be working now. —  Jts1882 | talk  08:30, 12 November 2021 (UTC)
Wonderful, thanks! Cheers, Micromesistius (talk) 15:45, 12 November 2021 (UTC)

Support for global ornithology checklists

Of the four main global bird checklists only Birdlife has entries on Wikidata. The Cornell checklist is represented by eBird, but their main database, Birds of the World, has no entry. As this shares an identifier with eBird, it's easy to add the BOW link, even though its not included at Wikidata.

So I've been WP:BOLD and made the change (e.g. see gray catbird). I reason that the goal of the taxonbar is to provide links to databases. Wikidata is the usual means to do this, but needn't be what determines what is worth linking. Thoughts? —  Jts1882 | talk  09:10, 17 November 2021 (UTC)

@Jts1882: I agree that Wikidata need not be a prerequisite for adding IDs to the Taxonbar, but if they're as important as you say, then they should probably be in Wikidata anyway. You can create property proposals @ d:Wikidata:Property proposal/Natural science.   ~ Tom.Reding (talk ⋅dgaf)  15:07, 19 December 2021 (UTC)

Purge, mass

Recently fossilworks.org changed URL formatting in Wikidata but it is not reflected in articles until the page is purged creating a situation with 30,000+ pages with dead links, example Desmophyllites has a taxonbar dead URL of http://www.fossilworks.org/bridge.pl?a=taxonInfo&taxon_no=14763 .. a purge would change it to http://www.fossilworks.org/cgi-bin/bridge.pl?a=taxonInfo&taxon_no=14763 .. how do we refresh every page so it displays correctly? -- GreenC 06:07, 18 December 2021 (UTC)

 Working   ~ Tom.Reding (talk ⋅dgaf)  07:37, 18 December 2021 (UTC)
 Done   ~ Tom.Reding (talk ⋅dgaf)  18:55, 18 December 2021 (UTC)
Awesome, thanks Tom.Reding. Do you mind if I ask how you did it? Is there a MWF API command to issue a null or empty edit on a page? -- GreenC 18:59, 18 December 2021 (UTC)
@GreenC: I added {{subst:null}} to each page to create a null edit via AWB. There were ~36,000 en.wiki pages using Fossilworks taxon ID (P842), so @ ~1 page/second it took ~10 hrs.   ~ Tom.Reding (talk ⋅dgaf)  14:06, 19 December 2021 (UTC)
I see interesting, thanks again for doing that. This inspired me yesterday to look into it and I found API:Purge which I added to Wikiget so for example from the command line: wikiget -G Paris would purge the Paris article. To generate the list of target articles: wikiget -a "insource:fossilworks insource:/fossilworks[.]org\/bridge/" > list.txt . -- GreenC 16:24, 19 December 2021 (UTC)

Lua error with Taxonbar?

Can anyone see what the issue is with this taxonbar for Gea eff (Q4281852)? When I type {{Taxonbar|from=Q4281852}}, I see:

Lua error: bad argument #1 to 'getEntityIdForTitle' (string expected, got nil).

Backtrace:

  1. [C]: in function "error"
  2. libraryUtil.lua:11: in function "checkType"
  3. mw.wikibase.lua:144: ?
  4. (tail call): ?
  5. Module:Taxonbar:475: in function "chunk"
  6. mw.lua:525: ?
  7. [C]: ?

Thanks! Not sure if I should be asking here or WT:LUA so I'm asking both places but will respond in both places when the issue is solved. Umimmak (talk) 04:57, 25 February 2022 (UTC)

See my response at WT:Lua#Lua error with Taxonbar?. Johnuniq (talk) 08:29, 25 February 2022 (UTC)

Empty from1 throws Lua error

The following code produces a Lua error:

{{Taxonbar|from1=|from2=Q106918135}}

Can the module be improved so that an empty definition does not cause this error? — Martin (MSGJ · talk) 18:04, 8 March 2022 (UTC)

Should taxonbar be used on redirects?

I'm leaning no, since the user would never really see it. But figured I'd check. Example. –Novem Linguae (talk) 22:36, 29 May 2022 (UTC)

I don't see any harm and it could be useful. Generally, the appropriate qid should be added to the taxonbar on the target page. A more useful thing is connecting the redirect page to the Wikidata item, as you have done in the example. For those who don't know, this needs temporary disabling of the redirect to allow the connection at Wikidata to be made. —  Jts1882 | talk  08:27, 30 May 2022 (UTC)

GRIN URL format change

It looks like Germplasm Resources Information Network have updated their URL format again, without redirecting. Current Taxonbar format (for a species):

https://npgsweb.ars-grin.gov/gringlobal/taxonomydetail.aspx?id=1234

Their new species format:

https://npgsweb.ars-grin.gov/gringlobal/taxon/taxonomydetail?id=1234

And their new format for a genus:

https://npgsweb.ars-grin.gov/gringlobal/taxon/taxonomygenus?id=5678

In general, it looks like they have dropped the .aspx part of the URL and added a /taxon component. Thanks, Declangi (talk) 22:43, 16 September 2022 (UTC)

This needs a Wikidata fix. Unfortunately the GRIN Wikidata items takes the full URL rather than just the id which is used to construct a url with a formatter URL property that could be easily changed. Each Wikidata item on a taxon (e.g. Rhododendron) has the full URL, which probably means this needs to be fixed by a Bot on Wikidata.
We could make a custom fix in the taxonbar code, which looks a simple enough "regex" replacement, something like "(taxononomy%a+).aspx?id=", "taxon/%1?id=" with appropriate escaping. But I think it might be best to wait to see if Wikidata make a solution or if GRIN add the redirects. —  Jts1882 | talk  07:20, 17 September 2022 (UTC)
Reported the change at Wikidata: https://www.wikidata.org/wiki/Property_talk:P1421#GRIN_urls_changed. —  Jts1882 | talk  08:23, 17 September 2022 (UTC)

Three missing properties (including NatureServe)

The following properties do not show up in the Taxonbar for a plant species. See Symphyotrichum lateriflorum as an example.

  • Freebase ID (P646)
  • NatureServe Explorer ID (P10243)
  • Open Tree of Life ID (P9157)

I am most interested in the NatureServe Explorer ID. Can it, or perhaps all three, be added?

Thanks in advance. – Elizabeth (Eewilson) (tag or ping me) (talk) 06:23, 25 September 2022 (UTC)

@Eewilson: Done as requested (you may need null edits to see results). However, I question the utility of the Freebase one. It's just a link to a Google search. Or am I missing something? —  Jts1882 | talk  13:04, 25 September 2022 (UTC)
Thanks! yeah, that's what I saw too. I don't know the purpose of Freebase. – Elizabeth (Eewilson) (tag or ping me) (talk) 13:07, 25 September 2022 (UTC)
Looks like it was an attempt to organise structured data on the web, with a similar goal to Wikidata. Google acquired freebase.com and then shut it down with a commitment to transfer the data to Wikidata (see here). The site closed in 2015. Not sure why Wikidata changed the link to a Google search. I'll disable it from the taxonbar. —  Jts1882 | talk  13:38, 25 September 2022 (UTC)

TaiBNET

I seem to remember a discussion where it was concluded that the Taxonbar should not show the TaiBNET (Catalogue of Life in Taiwan) ID because the database is in Chinese. But this is not quite true, the database exists in both English and Chinese. If you know the ID, the path leading to either version can easily be constructed, for example:

Therefore, I wonder if the TaiBNET ID could included? Micromesistius (talk) 15:53, 11 October 2022 (UTC)

Link to previous discussion. Language of databases isn't the only issue. I don't see a lot of value in databases with a regional focus that don't go beyond a checklist of valid/accepted species (and synonyms). There has been a proliferation of Wikidata properties for regional taxonomic databases. It's looking like Wikidata will eventually have properties for taxonomic databases focused on most individual states of the USA. I don't think all of those should be included, especially if they have little information beyond accepted/valid status. There's a property for Weeds in Ontario; it's a digitized version of a book, and while it does provide more information than accepted/valid, it's an incredibly narrow focus (only 11 Wikidata items have this property). Plantdrew (talk) 18:42, 11 October 2022 (UTC)
I see your point, but there is a difference between Weeds in Ontario and TaiBNET with 64878 species, which probably makes it quite complete for eukaryotes. In some case, there is no taxonbar-accepted ID, for example Nematopogon taiwanella. The information included varies though, and is probably minimal for most invertebrates. I wonder if there could be solution where regional IDs would be displayed only when there are none or few other IDs available? Micromesistius (talk) 20:07, 11 October 2022 (UTC)
I think the decision was not to show it automatically. It's listed in the Excluded_databases section of the taxonbar documentation. You can manually add it to an articele by editing the {{taxonbar}} template as follows:
{{Taxonbar/sandbox|from=Q6991032|CoL-Taiwan=343745-x}} //  manual override when wikidata (link deliberately corrupted)
{{Taxonbar/sandbox|from=Q6991032|CoL-Taiwan=yes}}    // get from wikidata
{{Taxonbar/sandbox|from=Q790586 |CoL-Taiwan=421738}} // manual when no wikidata
{{Taxonbar/sandbox|from=Q790586 |CoL-Taiwan=yes}}    // get from wikidata
You have to specify the Wikidata Qid. —  Jts1882 | talk  10:48, 12 October 2022 (UTC)
OK, that will do. Micromesistius (talk) 11:07, 12 October 2022 (UTC)
Working on modification so |CoL-Taiwan=yes retrieves value from wikidata. —  Jts1882 | talk  10:27, 13 October 2022 (UTC)
Hi, could you move this update out from the sandbox? Cheers, Micromesistius (talk) 12:15, 20 January 2023 (UTC)
@Jts1882 I'm specifically referring the "CoL-Taiwan=yes" update. Micromesistius (talk) 12:21, 20 January 2023 (UTC)

Collapse taxonbar parameter

Is there a parameter to force a manual collapse of the Taxonbar, or is that always automatic based on the number of taxon IDs (or other quantifier)? – Elizabeth (Eewilson) (tag or ping me) (talk) 00:35, 24 October 2022 (UTC)

I think it is automatic if 4 or more rows. I can't see any parameter. Can you give an example where you think this would be useful? —  Jts1882 | talk  09:42, 24 October 2022 (UTC)
It's 5 or more rows. Compare Acmispon junceus (4) with Cariacothrix (5) or Symphyotrichum lanceolatum (9). Seems fine as it is to me. Peter coxhead (talk) 11:09, 24 October 2022 (UTC)
So it is. Then it's not set where I thought it was (line 623). Perhaps it's a Navbar default. —  Jts1882 | talk  11:42, 24 October 2022 (UTC)
@Jts1882: I'd never looked at the Lua, just knew the behaviour empirically. But it does look as though line 623 is meant to determine the threshold. Odd... Peter coxhead (talk) 16:06, 24 October 2022 (UTC)
@Jts1882 and Peter coxhead: Nobody tagged me, and I forgot to subscribe to this thread, so I didn't see these replies until now and, of course, I forget which page I was working on at the time. I don't remember if it was a situation where there were fewer than 5 but they were big and I wanted to collapse them, or there were five and it didn't collapse. I think it was the former. If or when this trips me up again, I'll comment here and tag you folks. Thank you for the replies. – Elizabeth (Eewilson) (tag or ping me) (talk) 19:34, 14 November 2022 (UTC)

Why does this only show one line?

{{Taxonbar|from1=Q3305022|from2=Q80174}}

UtherSRG (talk) 13:07, 14 November 2022 (UTC)

The only identifier the Wikidata item for Panina has is Google Knowledge Graph ID, which taxonbar intentionally doesn't display. If there are no identifiers in a Wikidata item for taxonbar to display, there won't be a line for that item. Plantdrew (talk) 14:41, 14 November 2022 (UTC)
Oh! Duh. *sigh* Mondays.... UtherSRG (talk) 14:46, 14 November 2022 (UTC)
Ok, I've added a fossilworks entry, and yeah, now it shows. But it had a Wikispecies entry already. I guess that doesn't count. - UtherSRG (talk) 14:54, 14 November 2022 (UTC)
If I recall correctly, there are a few taxonomic databases that have some data quality issues, and the taxonbar won't display if the only identifiers in Wikidata are those databases. If there are other identifiers, the taxonbar will display and will show the database with quality issues. I think those databases are GBIF, EOL, and apparently, Wikispecies. It's a bit of a red flag if the only identifier in Wikidata is GBIF/EOL; it's likely that the record is a misspelling, or a synonym. Plantdrew (talk) 15:42, 14 November 2022 (UTC)
Fair enough. For cite templates, there's a setting we can use so that we see some maintenance errors. I wonder if it would be good if we had something similar so that we can see that the template is functioning, but is missing any valid data. f I had that mode on, I would have then searched to find (in this case) the fossilworks id. UtherSRG (talk) 15:54, 14 November 2022 (UTC)
There's a tracking category, Category:Taxonbars without primary Wikidata taxon IDs (it's hidden by default, you need to set your preferences to display hidden categories). Plantdrew (talk) 22:07, 14 November 2022 (UTC)
Ooof! Over 11k articles in that category. UtherSRG (talk) 22:44, 14 November 2022 (UTC)

WCSP dead now

Since the World Checklist of Selected Plant Families no longer exists, and any URL that attempts to go to it redirects to the front page of Plants of the World Online, as far as I can see it's no longer useful to have WCSP in a taxonbar, so it should be removed. Peter coxhead (talk) 11:46, 24 November 2022 (UTC)

Yes, it's completely useless now. I've commented it out for now, but even if they do eventually provide redirects to the POWO page, I don't see a need for keeping it. —  Jts1882 | talk  13:17, 24 November 2022 (UTC)

Lygaeoidea Species File ID

Since this module is protected, how do I get the Lygaeoidea Species File ID added to the taxonbar? Lygaeoidea Species File {Q115641818} Lygaeoidea Species File ID {P11311} Michael pirrello (talk) 21:12, 18 December 2022 (UTC)

@Michael pirrello: By asking here.  Done Example at Oncopeltus. It may take a while to become active, but you can check in preview mode. I'm not sure how many species have the ids at Wikidata. There isn't one for Oncopeltus zonatus, so the ids may need to be added manually unless there is a bot working on it.
Lygaeoidea Species File is unlinked in the taxonbar as there is no Wikipedia page (as for other species files databases). I wonder if there is a case a [{Species File]] article. —  Jts1882 | talk  07:37, 19 December 2022 (UTC)

Template-protected edit request on 4 January 2023

In Module:Taxonbar/conf, change the line:

{ 'FoC', '[[Flora of China|FoC]]', 1747 }, to

{ 'FoC', '[[Flora of China (series)|FoC]]', 1747 },

The link should be to the publication Flora of China (series), not the general article about plants growing in China (Flora of China) Plantdrew (talk) 22:24, 4 January 2023 (UTC)

 Done UtherSRG (talk) 23:18, 4 January 2023 (UTC)

I have recently added a link to the authority control template which allows editors to easily add identifiers to Wikidata. Clicking the icon in the template (see screenshot below) automatically adds any missing statements to Wikidata using a tool called QuickStatements. The link only appears when the Wikidata value is missing or different to the locally defined parameter.

Would there be any interest in adding something similar to this template? — Martin (MSGJ · talk) 21:40, 10 January 2023 (UTC)

It could be useful, but I don't think I follow what it does and how it would operate with taxonbar. It appears when what Wikidata value is missing. Taxonbars often use more than one qid to retrieve identifiers, so at least one qid would be different by design. Taxonbar looks for a large number of identifiers and most won't apply to any particular taxon, so there will always be some identifiers missing for a particular taxon entity. —  Jts1882 | talk  16:57, 13 January 2023 (UTC)
A made-up example: if I type {{taxonbar|plazi=31F96F41-E3E0-02BD-8898-5A4P3A20E45A|from=Q674455}} then the plazi identifier should be moved to Wikidata. A link can be provided to quickly add that statement to Wikidata. Perhaps you don't have any of these locally defined parameters anymore, in which case there would be little benefit? — Martin (MSGJ · talk) 20:11, 22 January 2023 (UTC)
I see. That could be useful. I see hardly any locally defined parameters with taxonbar, but I can't say if this is just the taxon groups I tend to edit or more general. I think the Wikidata bots fill up the taxon identifiers quite efficiently. —  Jts1882 | talk  09:46, 23 January 2023 (UTC)
There are 135 pages in Category:Taxonbars with manual taxon IDs. That could be reduced by cleaning out Category:Taxonbars with manual taxon IDs identical to Wikidata (and possibly Category:Taxonbars with manual taxon IDs differing from Wikidata). Plantdrew (talk) 17:28, 23 January 2023 (UTC)
So the Quickstatements tool would make it easy to clear those categories. —  Jts1882 | talk  17:40, 23 January 2023 (UTC)

Is it possible to ask to add the links to taxa from the databases of the International Fossil Plant Names Index (IFPNI) [1] and Nomenclator Zoologicus [2] to the taxonbar?. Very useful databases, but not included (overlooked) in current version of taxonbar. Anna Pavlova IFPNI Staff (talk) 22:30, 19 February 2023 (UTC)

@IFPNI Staff: The taxonbar retrieves information from Wikidata. For that to work the database source requires an identifier on Wikidata. There is one for IFPNI species ID (P6341), which I have added to the taxonbar module. There is a working example at Barley.
Wikidata doesn't currently have an identifier for Nomenclator Zoologicus. To create one, a proposal would have to be made at Wikidata. See Property_proposal/Natural_science. —  Jts1882 | talk  07:27, 20 February 2023 (UTC)
Dear colleague! Thank you for your explanation and suggestion, but being a taxonomist I first time met a Stalingrad with this proposal))) I am sorry, but the form is overcomplicated for scientists. Could you please to suggest any advanced people here in the Wikidata community, who could assist in writing such a formal proposal? Anna Pavlova IFPNI Staff (talk) 21:34, 20 February 2023 (UTC)

Basionym (original combination) displayed when from parameter is wrong

When an en.wiki article is linked from Wikidata, and Wikidata has a basionym/original combination specified, and the taxonbar from parameter is wrong (i.e., the parameter is a Wikidata item, but not the one for the subject of the article, or the from value isn't a Wikidata item at all (the case I encountered had "????" in the from parameter)), the taxonbar will display the basionym. When I came across a case of this I was very confused. Why was the taxonbar link to POWO a record about a variety that POWO said was (a synonym of) a full species? Was it a situation where somebody had wrongly changed the taxon name on Wikidata? I eventually figured out what was going on.

This should be a very rare situation. It should only emerge for articles in Category:Taxonbars desynced from Wikidata; and for those articles should only emerge when a basionym is specified in Wikidata (which isn't very often). The desynced category has more than 3k entries, which is not good (it is the largest subcategory of Category:Taxonbar cleanup that needs actual cleanup). There are categories for Category:Taxonbars with unknown parameters and Category:Taxonbars with unnamed parameters. OK. There are many possible ways taxonbars may have bad parameters. I'm not particularly enthusiastic about adding more, but a from parameter that doesn't match Q[0-9]+ (not sure I've got the regex correct there; I intend a Q followed by multiple numerals) would not be a valid parameter. Plantdrew (talk) 02:17, 25 April 2023 (UTC)

Hi, the URL that the Environmental Conservation Online System (ECOS) parameter is linking to is out of date. Here is an example of the new format for golden-cheeked warbler, versus what taxonbar currently links to. 108.18.207.147 (talk) 18:00, 1 May 2023 (UTC)

I've updated ECOS ID (P6030) at Wikidata to use the new URL format. The new links work in the taxonbar, but the examples on Wikidata don't. Not sure if this is a caching issue or if I've not changed all the necessary items at Wikidata.
I added the identifier to Golden-cheeked Warbler (Q27075939) as Setophaga chrysoparia is now used in the title of the ECOS page. However, the General Information on ECOS continues to use Dendroica chrysoparia. I assume this is an oversight and ECOS haven't properly updated the record. —  Jts1882 | talk  07:10, 2 May 2023 (UTC)

Manual taxon IDs (CoL-Taiwan)

Gymnothorax taiwanensis is currently in Category:Taxonbars with manual taxon IDs because it has |CoL-Taiwan=, however, the parameter is set to "yes" not to a manually added identifier, and without it the identifier (which is on Wikidata) doesn't display. Is this a false positive or is it intentional? – Scyrme (talk) 12:29, 30 May 2023 (UTC)

A few more of these: Rhinogobius candidianus, Somatochlora taiwana, Stenolemus alikakay. There may be others. – Scyrme (talk) 13:04, 30 May 2023 (UTC)
I think this is now fixed, although not yet showing up on the category pages. I unintentionally created the problem in January when I added the 'yes' option to allow optional identifiers such as Col-Taiwan to use Wikidata for the source instead of requiring a manual entry. The category was set elsewhere in the code when the value was not 'no'. —  Jts1882 | talk  08:39, 31 May 2023 (UTC)
@Scyrme: I've null edited the articles and they are no longer in the category.
I've also removed the e-Monocot and emonocotfamilyes identifiers from the three remaining articles in the category, as e-monocot.org site has been discontinued by Kew. The tracking category is now empty. —  Jts1882 | talk  14:00, 31 May 2023 (UTC)
Great! Thanks. – Scyrme (talk) 18:50, 31 May 2023 (UTC)

Fossil egg taxa

Category:Taxonbars on possible non-taxon pages lists ichnotaxon (Q2568288) and fossil taxon (Q23038290) as whitelisted. Should ootaxon (Q59278506) (a subclass of fossil taxon (Q23038290)) also be whitelisted? Since ichnotaxa are whitelisted, I don't see why not. This would clear a few articles from Category:Taxonbars on possible non-taxon pages, like Elongatoolithus. Or were they intentionally excluded? – Scyrme (talk) 19:30, 31 May 2023 (UTC)

I don't see any reason to exclude them. More likely ootaxon is a newer addition. Ideally subclasses would be included automatically, but a simple allowed list is much simpler. Added. —  Jts1882 | talk  08:17, 1 June 2023 (UTC)
Thanks! – Scyrme (talk) 16:29, 1 June 2023 (UTC)

Obsolete taxa

Should obsolete taxon (Q110533142) also be whitelisted? (Asking because Monera is in Category:Taxonbars on possible non-taxon pages.) – Scyrme (talk) 23:22, 1 June 2023 (UTC)

There are only 9 Wikidata items linked to that, only 2 of them have any identifiers that taxonbars would display, and Monera is the only one with displayed identifiers that has a English Wikipedia article. Might be better just to remove the taxonbar from Monera. Plantdrew (talk) 00:16, 2 June 2023 (UTC)
The WoRMS entry for Monera is a dead link so I've removed it from Wikidata. The ITIS entry has it as an invalid taxon. I changed the Wikidata item for ITIS to deprecated rank (rather than normal) which removes the taxonbar. I'm not sure this is an appropriate use of deprecated on Wikidata as there is a an entry on ITIS.
As a general point, I think that if there is an article on an obsolete taxon, then the the module should display a taxonbar if there are appropriate Wikidata entries. Whether there should be an article or whether it should have a taxonbar should be decided on the article talk pages. —  Jts1882 | talk  09:06, 2 June 2023 (UTC)

PaleoDB

Is there a reason why the taxonbar doesn't have a parameter for the Paleontology Database? From my understanding, it is the successor of Fossilworks, which does have a parameter, but Fossilworks is no longer being updated. Happy editing, SilverTiger12 (talk) 01:50, 11 June 2023 (UTC)

It seems the relevant property on Wikidata is Paleobiology Database taxon ID (P10907). I suspect it hasn't been added to Taxonbar because it's relatively new; the Wikidata property was created in August, 2022; it's less than a year old. – Scyrme (talk) 02:16, 11 June 2023 (UTC)
Ah. Could someone who knows how this template works please add it? Happy editing, SilverTiger12 (talk) 02:27, 11 June 2023 (UTC)
 Done Example at Palaeobatrachus.
The history of fossilworks and the PaleobioDB is complicated (or do I mean confusing). As far as I can make out, the Paleobiology Database and Fossilworks were both set up by John Alroy at Macquarie University, with fossilworks being the public face of PaleobioDB. Then a second site was setup at University of Wisconsin-Madison with its own portal to the Paleobiology DB. Changes to the database were made at Madison and Fossilworks was supposedly updated daily from there. While this suggests they use the same database content, there are subtle differences in the page displayed that suggest they are not exact mirrors. —  Jts1882 | talk  08:31, 11 June 2023 (UTC)

Strains

A number of pages in Category:Taxonbars on possible non-taxon pages are instances of strain (Q855769) or its subclasses (bacteria strain (Q69897544), viral strain (Q18420531)). Strain is itself a subclass of taxon (Q16521). Should strains be whitelisted? – Scyrme (talk) 00:54, 2 June 2023 (UTC)

How many of them aren't also in Category:Taxonbars without primary Wikidata taxon IDs? SARS-CoV-2 is one, but the BioLib and Plazi links there are wrong (BioLib goes to a page for a jellyfish, and Plazi goes to a particular study), and the EOL link has no data whatsoever. I don't expect most strains to have any primary taxon IDs on Wikidata currently or in the future. Remove the taxonbar and clear out entries from two subcategories of Category:Taxonbar cleanup at once (and also consider removing (at least temporarily) serotype (Q848328) from the whitelist for the non-taxon pages category, and see if there are a bunch of serotypes with no primary IDs).
If taxonbars get re-added by somebody using (semi-)automated tools based on the presence of a taxobox template, get that editor to blacklist Category:Infraspecific virus taxa (and create a similar category for bacteria). Plantdrew (talk) 02:19, 2 June 2023 (UTC)
Fair point. If they aren't likely to get ids, there's not much benefit having taxonbars on them. – Scyrme (talk) 03:01, 2 June 2023 (UTC)
From the perspective of the module logic, I'd say any subclass of taxon should be whitelisted and not placed in a non-taxon category. The merits of including a taxonbar on the stain pages is secondary. —  Jts1882 | talk  08:54, 2 June 2023 (UTC)
It would certainly make things simpler from my perspective if they were automatically whitelisted, since it would save having to edit each page to remove the taxonbar. It doesn't cause any problems for the reader if a taxonbar is used on pages that don't have any primary taxon ids, since the bar simply won't display.
Thinking about it, regarding Category:Taxonbars without primary Wikidata taxon IDs, I'm not sure that it can be categorically said that strains are likely to remain there indefinitely. NCBI taxonomy ID (P685) includes viral strains, including an id for SARS-CoV-2. I've had a quick look at strains in both categories, and it seems many have an NCBI taxonomy id but it just hasn't been added to Wikidata yet. – Scyrme (talk) 19:57, 2 June 2023 (UTC)
I guess removing taxonbars from strains with no IDS would just end up putting pages in Category:Taxobox articles possibly missing a taxonbar instead. So whitelist strains. Plantdrew (talk) 00:24, 5 June 2023 (UTC)
@Jts1882: I think we're in agreement now regarding whitelisting strains. – Scyrme (talk) 08:57, 14 June 2023 (UTC)

False positives: articles covering both a common name and taxon

Gecko is currently flagged for Category:Taxonbars on possible non-taxon pages because although Gekkota (Q1008888) is a taxon, gecko (Q16546828) is not. However, Gecko is actually the article for both "Gekkota" and "Gecko"; there is no separate article for the former, and Gekkota (Q1008888) lists the redirect Gekkota for the English Wikipedia page.

In cases like Gecko I don't think {{Taxonbar}} is irrelevant just because the article is located at the common name. It shouldn't be flagged as a 'possible non-taxon page' when the article's content clearly pertains to a taxon like this. While Gecko could be added to the whitelist, it seems likely there are other pages in a similar situation with a single article for both the common name and taxon but separate Wikidata items for each where the article is located at the common name but the topic of the article is identical with the taxon.

Is there a way to have the template/module check not only the article's Wikidata item for taxon (Q16521) but also check the items for its redirects? If that would cause unforseen problems, perhaps it could be programmed to only do so if the Wikidata item for the article itself has "instance of organisms known by a particular common name (Q55983715)", so that it only checks redirects where it's likely that an article covers both a common name and a taxon.

An automatic solution would help remove false positives like Gecko from Category:Taxonbars on possible non-taxon pages without requiring each to be manually identified and whitelisted by someone with permission to edit the template/module. – Scyrme (talk) 16:04, 28 May 2023 (UTC)

Actually, thinking about it, the redirects aren't necessarily a good indicator of whether the target article is a taxon titled under a common synonym. It's also not very efficient to check all the redirects. A better solution might be to check only the Q ids listed by "from" parameters to see whether they are connected to a redirect targeted to the article which has the taxonbar. Is that a feasible solution? – Scyrme (talk) 00:44, 29 May 2023 (UTC)
I think the problem is at Wikidata, which has entries covering the same taxon at the scientific name and common name. Usually there is one entry for a taxon which can have a label set to either of the names. For instance, the taxon entry for the lion (lion (Q140)) has the label lion, but there isn't separate entry for Panthera leo. Such confusion is partly because Wikidata blurs the line between the taxon (a defined group) and the taxon name (which can have different circumscriptions). —  Jts1882 | talk  08:36, 30 May 2023 (UTC)
Merging the Wikidata items may not be viable. Many different language Wikipedias have separate articles for each. I suspect the articles should also be merged, but that's something for each respective Wikipedia to sort out. As long as separate articles exist, the problem on the English-language Wikipedia can't be fixed by merging the Wikidata items. Or is there solution for this? – Scyrme (talk) 10:45, 30 May 2023 (UTC)
I don't see a reliable way of determining if the page refers to a taxon algorithmically. One solution would be to add a parameter to {{taxonbar}} to indicate the page is a taxon, e.g. |taxon=true or |is_taxon=true. This would have to be set manually on each page, but would clear the category of pages that are on valid taxa. —  Jts1882 | talk  08:44, 31 May 2023 (UTC)
That could work, but pages with the parameter may still need to be checked from time to time. I'm not convinced that Gekkota is the appropriate taxon to associate with "gecko"; I think people searching for that term are more likely to be interested in Gekkonidae. Wikipedia might re-establish an article on Gekkota, and changes the gecko article to cover the family (although I guess that wouldn't affect a "true" parameter; but the |from= value would need to be changed). The Wikidata item for "gecko" has "organisms known by a particular common name" with "of" "Gekkota", which is something I haven't seen before (although now I see that fish (Q152) has "of" as well . Maybe "of" could be added to Wikidata items for some of these and "organisms known by a particular common name" with "of" could whitelisted? Plantdrew (talk) 15:40, 31 May 2023 (UTC)
A quick look at the common names of species in various families finds six of the families with geckos of various types. Pygopodidae is the exception where the names include delmas, worm-lizards, sliders and scaly-foots. I don't know the history, but as the Pygopodidae are legless their association with geckos could be relatively recent, perhaps making gecko in the common name sense paraphyletic, in the way lizard is. But the scientific sources use gecko for the whole group. —  Jts1882 | talk  16:02, 31 May 2023 (UTC)

The "of" qualifier is often used on paraphyletic groups, like fish (Q152). Is {{taxonbar}} appropriate for articles about paraphyletic groups, like Fish?

If yes, then, neither Gecko nor Fish should be in Category:Taxonbars on possible non-taxon pages. Whitelisting "of" could work. An alternative might be to whitelist paraphyletic group (Q58051350), but that would raise the question of whether gecko (Q16546828) etc. should be marked as one. Whitelisting organisms known by a particular common name (Q55983715) when it has an "of" qualifier makes the question irrelevant; it would fix the categorisation regardless.

If no, whitelisting based on "of" wouldn't work. In this case, it matters whether Gecko is polyphyletic or monophyletic; the same question has to be answered for all the other articles located at a common name title on a case-by-case basis. If it is monophyletic, then its Wikidata item should be labelled as an instance of clade (Q713623) (which is already whitelisted) and if it isn't it should be labelled as an instance of paraphyletic group (Q58051350). (These would both be in addition to labelled them as organisms known by a particular common name (Q55983715), not instead of.) This would then make it clear whether {{Taxonbar}} should be kept or removed. – Scyrme (talk) 19:23, 31 May 2023 (UTC)

@Jts1882 and Plantdrew: Another option could be to use said to be the same as (P460) on the Wikidata items for these common names, and whitelist that if it points to a taxon. Would that work? – Scyrme (talk) 02:59, 2 June 2023 (UTC)
Looking at the items using said to be the same as (P460) I don't think that is appropriate. In line with my comments on other subclasses of taxon (see below), I think paraphyletic group should be whitelisted. —  Jts1882 | talk  09:13, 2 June 2023 (UTC)
@Plantdrew: What do you think about whitelisting paraphyletic group (Q58051350)? – Scyrme (talk) 09:04, 14 June 2023 (UTC)
I'd be fine with that. Plantdrew (talk) 13:46, 14 June 2023 (UTC)
 Done It is a subclass of taxon so logically should be whitelisted. Is there an example of a page in a category that this should fix? —  Jts1882 | talk  14:38, 14 June 2023 (UTC)
Thanks! Anamniotes is one that has now been cleared from Category:Taxonbars on possible non-taxon pages. – Scyrme (talk) 17:57, 14 June 2023 (UTC)

Taxonbar not displaying

When I was attempting to add the taxonbar for Tritonia punctata, adding its item (Q7844388), the taxonbar doesn't display. I made sure to use the correct syntax, and I know I didn't misspell it, so I have no idea what's going on. Does anybody know how to fix this? Millows! | 🪧 04:39, 9 August 2023 (UTC)

There's nothing to fix. The Wikidata item doesn't have any identifiers associated with it for the template to display. When the taxonbar is empty, it simply does not display. I tried looking for some relevant identifiers to add, but wasn't able to find any. Perhaps the species is generally known by a different binomial name? – Scyrme (talk) 06:11, 9 August 2023 (UTC)
(edit conflict)
Taxonbars only display when there are suitable taxon identifiers at Wikidata and the only identifier there is is freebase.
This species doesn't seem to be recognised by recent authorities. WoRMS doesn't list it as a species or synonym (see Tritonia). I believe WoRMS follows the latest classification of gastropods by Bouchet, who is author of the 2005 article cited. Is there a recent source recognising this species? —  Jts1882 | talk  06:12, 9 August 2023 (UTC)
The article was created in 2010 by a former admin who is no longer active. It was part of bulk creation of stub articles (see here). It had the same single source then as now and the source doesn't list the species in the genus. I can't find any other reference to this species. The species listing at Tritonia is also unsourced. A recent reference was added to the article but the list preexisted it and isn't supported by the reference. —  Jts1882 | talk  06:45, 9 August 2023 (UTC)
@Millows: I found a instance of a database with this species and added the identifier to Wikidata. The taxonbar now displays without any changes here on Wikipedia. This confirms that there was no problem as explained above. However, whether it should remain an article is still a question. —  Jts1882 | talk  10:59, 9 August 2023 (UTC)

Taxonbar does not load

In Iotatorquevirus, i have 4 taxonbars (see source code), but it shows 3 (see article/visual).

  1. Q6064135, which is for Iotatorquevirus loads
  2. Q118466029, which is for the current name of the only species under Iotatorquevirus,Iotatorquevirus suida1a DOES NOT LOAD
  3. Q18966330, which is for one of the two previous species before they were merged, Torque teno sus virus 1a loads
  4. Q18966334, which is for one of the two previous species before they were merged, Torque teno sus virus 1b loads

WHY IS THIS???

>>> Webclouddat (talk) 03:14, 14 August 2023 (UTC)

The entry for Iotatorquevirus suida1a (Q118466029) doesn't have any identifiers. The taxonbar only displays if there are external identifiers in addition to the Wikimedia ones (Wikidata, Wikispecies). —  Jts1882 | talk  06:38, 14 August 2023 (UTC)
can one (you) add identifiers??
>>> Webclouddat (talk) 06:45, 14 August 2023 (UTC)
Yes. I just added the identifier for NCBI and the taxonbar now displays. You can add them yourself at Wikidata using the add statements option near the bottom of the Wikidata page. If you need help, provide the links to the page of the resource for the virus here and I can add them. —  Jts1882 | talk  07:27, 14 August 2023 (UTC)
the Wikidata and NCBI displays and links, thanks!
i do not know how wikidata works, and i do not want to touch it nor learn it
>>> Webclouddat (talk) 07:33, 14 August 2023 (UTC)
(wikispecies does not have a page on Iotatorquevirus suida1a) Webclouddat (talk) 07:34, 14 August 2023 (UTC)

First valid description

Hello, the taxonbar on Varanus marathonensis, via wikidata item Q12009011, currently has an entry for BHL, which takes you to the first valid description; however, this use of BHL page id as an identifier in wikidata results in a constraint conflict, and there seems to be limited appetite for related change there; instead, on wikidata item Q30682478 for Canis etruscus, the taxon name has a reference with "reference has role" "first valid description"; how can we enable the taxonbar to pick up, potentially as the first entry after wikidata and wikispecies, the bhl page/doi/hdl/url for the first valid description (potentially entitled "description: bhl/doi/hdl/url" and, potentially, subsequent nomenclatural acts, using "reference has role" "recombination")? Thanks, Maculosae tegmine lyncis (talk) 20:17, 13 August 2023 (UTC)

I'm not sure I understand the problem/question, but here goes.
  • The taxonbar for Varanus marathonensis seems correct with the BHL entry. The constraint message at Wikidata is because they don't want to use taxon name and BHL page ID on the same item. I assume they was the BHL page ID as a reference for the name, but then the taxonbar won't pick up the the BHL identifier. This makes no practical sense, as Wikidata should prioritise being a utility for other Wikimedia projects over some pedantic view of how the data should be structured. This probably means a lot of BHL identifiers are not readily available to the taxonbar.
  • Now maybe I understand you question. The BHL page ID is used in the reference for the taxon name for Canis etruscus (Q30682478) and not there as an identifier in the statements. In principle the information could be retrieved by the taxonbar, but I'm not sure it should. The purpose of the taxonbar is to pick up identifiers listed as statements in the Wikidata item. There would be considerable overhead in searching for potential identifiers tucked away in references. And could we be sure that the identifier in the reference is the correct identifier for the Wikidata item (and not a synonym). The first valid description of the taxon name should be correct, but Wikidata is muddled on whether items are about taxon names or taxa.
  • For taxa that have been renamed, separate identifiers should be added to the taxonbar for basionyms/original combinations using the |fromN= parameter.
The best solution would be for Wikidata to be more flexible and allow the information in two places. The identifiers are part of the data, while the reference is supporting that data. You shouldn't have to look in the reference for parts of the data on the item. @Peter coxhead: Any thoughts? —  Jts1882 | talk  08:08, 14 August 2023 (UTC)
Completely in agreement, but as per here, there is not necessarily the Wikidata flexibility; my watchlist has more than once shown BHL pages I have added as identifiers, to allow the wikipedia taxonbars to pick them up, being removed by other editors; I raised this last year with another user here, similarly to no avail, Maculosae tegmine lyncis (talk) 11:11, 14 August 2023 (UTC)
Those are typical responses from the Wikidata Priesthood. This is the sacred and only way. Occasionally an admin will intervene and allow some common sense, but its rare.
An alternative is to add the identifier to the taxonbar manually: {{taxonbar |from=Q30682478 |BHL=34891310}}
Not ideal, but at least you can add the information to the article. —  Jts1882 | talk  12:09, 14 August 2023 (UTC)
Wikidata's BHL id is not a taxon/name ID; it's an ID for a particular publication on BHL. For most taxa, BHL will have multiple publications which mention it. The original description is a particularly important publication, but for any species that has been transferred to another genus, there will be another publication that is also important (more so for plants than animals). Plantdrew (talk) 16:59, 14 August 2023 (UTC)
How would you suggest we populate the taxonbar across all projects with the relevant publications? A page from the publication Amphibian Species of the World is accepted as a taxon ID, why not from the original publication to which the BHL page id points? There will be many BHL pages - so we could have the new identifier "BHL page of first valid reference id", or combine the existing with "reference has property" "first valid reference", in case many are added, or have a new identifier "first valid description", which can be populated by the bhl/doi/hdl/url... Would the transfer to another genus be served by the |fromN= plus the identifier, on the page for the new name, "BHL page of recombination id", or simply the existing BHL page id with the addition of "reference has property" "recombination", in case many pages are added (again, how do we efficiently return the doi/hdl/url if not bhl)? Thanks, Maculosae tegmine lyncis (talk) 17:35, 14 August 2023 (UTC)

Module:Taxonbar/whitelist & the sandbox

I recently made Module:Taxonbar/whitelist, to make modifying the whitelist easier/more intuitive, remove redundancy within the list, and to automatically produce an ordered list for use on Category:Taxonbars on possible non-taxon pages and possibly as a new section in the documentation. I'm about to incorporate the whitelist into the sandbox, and then to the live module.

@Jts1882: I see you've made some significant sandbox edits that aren't reflected in the live module yet. Should I include them when I eventually update live, or do you want to do that before I do, or should I ignore the sandbox changes entirely?   ~ Tom.Reding (talk ⋅dgaf)  18:20, 20 August 2023 (UTC)

Those sandbox changes are experimental, possible help for a new NSPECIES proposal. The first changes were made without synching the sandbox so my last whitelist additions were not included. The archived talk page discussion also suggests strains should be added to the whitelist.
I suggest synching the sandbox with the live version for your changes. I can restore my modifications later. —  Jts1882 | talk  20:03, 20 August 2023 (UTC)

The expensive parser function count (EPFC) is too damn high

Template:Taxonbar/doc has reached the EPFC limit of 500, so I looked at each section to find where the highest usages are:

  1. #More taxon examples: 196
  2. #List of taxon identifiers: 137
  3. the next highest sections have counts of 39, 30, 28, and trail off from there

We should try to show #List of taxon identifiers in its entirety if at all possible, so I suggest either trimming #More taxon examples, or substituting less expensive examples there. To that end, I made a list of all #More taxon examples's EPFCs (the first 3 are the most expensive):

   Display Order    QID    {{Q}}    EPFC
1 Q47685 Coffea arabica (Q47685) 28
2 Q158295 Asclepias syriaca (Q158295) 29
3 Q212398 Danaus plexippus (Q212398) 30
4 Q35694 jagua (Q35694) 22
5 Q600880 Eastern Bluebird (Q600880) 25
6 Q25420 Lampyridae (Q25420) 21
7 Q131227 Amanita muscaria (Q131227) 21
8 Q719725 Saccharomyces cerevisiae (Q719725) 17
9 Q132644 Lactobacillus acidophilus (Q132644) 9
10 Q311383 Plasmodium falciparum (Q311383) 6

~ Tom.Reding (talk ⋅dgaf)  14:32, 17 September 2023 (UTC)

  • Trim the section. The More taxon examples section is not strictly necessary so three or four examples is plenty. —  Jts1882 | talk  15:23, 17 September 2023 (UTC)
    @Tom.Reding and Jts1882: I've gone ahead and trimmed the examples.
    It now consists of a plant, an animal, a fungus, a bacterium, and a protozoan. The remaining examples cover the range of the variety that was present in the original list inlcuding what it looks like when there are many identifiers linked (Q47685), when there are only a few (Q311383), and when there are identifiers for multiple names (Q35694 and Q131227).
    Does it need further trimming? – Scyrme (talk) 21:12, 20 September 2023 (UTC)
@Scyrme: 389/500 now, so I think it's good for a bit :)   ~ Tom.Reding (talk ⋅dgaf)  02:27, 21 September 2023 (UTC)

Missing Property

Can World Arachnid Catalog (World Arachnid Catalog ID (P11803)) be added, It doesn't seem to show up in the taxonbar for the related species. Zacmh (talk) 19:45, 20 September 2023 (UTC)

 Done   ~ Tom.Reding (talk ⋅dgaf)  11:52, 21 September 2023 (UTC)

‎MilliBase taxon ID

Please add ‎MilliBase taxon ID (P12271). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:08, 4 January 2024 (UTC)

 Done Example: Anthogona britannica. —  Jts1882 | talk  20:38, 4 January 2024 (UTC)
MilliBase stub created, if anyone would like to add to it.   ~ Tom.Reding (talk ⋅dgaf)  21:16, 4 January 2024 (UTC)
@Pigsonthewing:, given your opposition to d:Wikidata:Property proposal/Plants of the World online, I am puzzled why you proposed Wikidata:Property proposal/MilliBase taxon ID. Did you change your mind completely? POWO/IPNI at least have a few ID #s that are different between the two sites.
MilliBase uses the Aphia platform (same as WoRMS). As far as I can tell, all MilliBase ID #s are identical to WoRMS (are there any that are not?), and MilliBase/WoRMS records have identical edit histories. I don't see why a MilliBase property is necessary. Some of the Aphia data can only be accessed at marinespecies.org (e.g. for various marine invertebrates), while some can also be accessed via other URLs (e.g. millibase.org or compositae.org) that only provide a subset of taxa in WoRMS. Is there any Aphia data that can NOT be accessed via marinespecies.org? I'll admit that it's counter-intuitive to expect marinespecies.org/World Register of Marine Species to have data on millipedes or Compositae, but it does. Maybe the WoRMS property should be renamed to Aphia? Does Wikidata want properties for every Aphia dataset that can also be accessed at URLs other than marinespecies.org?
I've been meaning to comment on the recent Wikidata property proposals for various "portals" of the Symbiota platform (portals representing different consortia of regional herbaria). Most of the Symbiota portals use identical ID #s for taxa (the default search behavior within most portals is to search all the other portals that share ID #s). There isn't any way to search "Symbiota" without going through a portal that I have been able to find (I guess searching torcherbaria.org (Texas Oklahoma Regional Consortium of Herbaria) and by default getting search results from SouthEast Regional Network of Expertise and Collections (the reverse also works; go to sernecportal.org and the default search will get results for Texas and Oklahoma) is kind of similar to getting millipedes and composites at marinespecies.org). Plantdrew (talk) 21:05, 4 January 2024 (UTC)
The WoRMS interface and specialist ones are not always identical, although nearly always have common records. For instance, the Global Compositae Database has 33,023 species (treeview) while WoRMS has 33,026 (treeview). WoRMS recognises Xerochrysum gudang (record created in 2022, (AphiaID=1617295), while GCD doesn't (AphiaID=1617295 missing). It seems GCD has a mirror that hasn't been updated, which is odd as I thought WoRMS was acting as the host site. The numbers in MilliBase and MolluscaBase match, at least currently.
As to whether there should be separate identifiers, MilliBase and MolluscaBase are more intuitive than those to WoRMS, which people will associate with marine species. Having separate IDs for taxa with large terrestrial subgroups makes some sense.
The IRMNG also uses the Aphia platform and can't be accessed through the WoRMS site. —  Jts1882 | talk  10:57, 5 January 2024 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Taxonbar/Archive_7&oldid=1205062131"