Bumblebee subgenera need correction, example: Pyrobombus

[bdagley]

Searching for the genus Bombus returns a page only listing species without subgenera as immediate children taxa (https://www.gbif.org/species/1340278). Starting a new search for the subgenus Pyrobombus returns a page where it is incorrectly categorized as a genus and has no parent or children taxa (https://www.gbif.org/species/4669778) ("Published in: Naturhistoriker, 2 source: The Interim Register of Marine and Nonmarine Genera").

Ideally in time GBIF will be updated to accommodate the subgenus rank, especially for wildlife groups of high interest and value like Bombus, although my understanding is that doing so isn't currently possible. In the meantime, is there any correction that can be made to these Pyrobombus records, such as moving them to the immediate parent taxon, genus Bombus? Or if nothing can be done, this flag could remain open just to indicate that Pyrobombus is supposed to be a subgenus.

[bdagley]

One further thought on this is that I believe when the synchronization between iNaturalist and GBIF was first created there were only bee (and for most all taxa) genera and species (e.g., Bombus), not subgenera (e.g., Pyrobombus), which could be considered an "infrarank." The subgenera were later added to iNaturalist, but not added to GBIF. Ideally, no infraranks would have been added to iNaturalist in the past without discussing or realizing the issue this would cause on GBIF.

Regardless, this raises of the question of whether there's anything iNaturalist can do to fix this, vs. I was originally thinking this was mostly a GBIF issue. At minimum, it would seem ideal for some discussion between iNaturalist and GBIF to be had about this. That said, it may also be possible that no one realized this issue would or did occur, although it's also ideal to fix in time.

For the time being, if possible, it would probably be best for the subgenus records to matriculate as genus records, but using the correct genus epithet. Currently, the subgenus (Pyrobombus) iNaturalist records are matriculating to GBIF as genus "Pyrobombus."

[bdagley]

To give a shorter summary of the issue from my earlier above comment, my guess is that the original iNaturalist-GBIF synchronization only included ranks that would display on GBIF for genus, species, etc., but not subgenera ("infraranks"); that iNaturalist later added infraranks including subgenera to it's own website, but that GIBF didn't add the subgenus rank; and consequently that GBIF currently interprets the matriculated iNaturalist subgenera records as if they're genera, or "bumped the records up to that rank," lacking any other rank between genus and species to categorize them in. This currently affects almost 7,000 records for the well-known bumblebee genus Pyrobombus alone.

Despite that the issue in some senses seems to be that GBIF currenly lacks subgenus as a rank, it would seem to at least warrant discussion between iNaturalist (e.g., @kueda) and GBIF, since the cause (adding subgenus to iNaturalist) seemed to have occurred due to an iNaturalist decision that didn't anticipate this issue occurring on GBIF or that was made without informing GBIF. For example, if at the original time such a discussion was had before adding subgenus, GBIF could've either advised against doing that (at least until/unless GBIF could add subgenus), or some plan between one or both websites could've been made to add subgenus ranks on GBIF. As mentioned, this also seems to affect other important infraranks that would technically be ideal to also address in the same way (e.g. subfamily, tribe, subtribe, subgenus, complex).

[bdagley]

Hi all, I just want to make one general observation here, partly because this is the oldest of the 3 at least partly iNaturalist-related Issues I've created, one of which I already closed. In the current Issue, I tagged inat staff a week ago). The other Issues are here (where GBIF staff tagged inat staff in Dec. 2023, and implied that I can create Issues on the iNat repository) and here (where I tagged inat staff a week ago, in my first and only Issue made on the iNat repository).

Almost all of my GitHub volunteer work to date has been for GBIF and/or COL, and @ManonGros, @mdoering and others have been very welcoming, appreciative of my corrections, suggestions, and feedback. Yet, it does seem noticeable that no iNat staff/admin members replied or even annotated/assigned in any way any of the mere 3 Issues that involve iNat and/or GBIF/COL that they were tagged in, including the one where a GBIF admin was the one who first tagged them. The pattern may seem to be that if I'm at all involved in an Issue where they get tagged by anyone, iNat ignore those Issues, although for now I'll assume the best and give them the benefit of the doubt, that maybe they just didn't notice the tags (from weeks to months ago) or didn't have time to make any comment/annotate/assign actions on them yet.

Yet, what I am requesting, is that at least some member(s) of the iNat staff/admin/devs, or even an intermediary/middle person in the unknown event that they for some reason refuse to speak to me, do at least eventually and typically respond/acknowledge the Issues I made. As it is, I've barely made any iNat-related Issues, and merely one on their own repository, etc. I also don't plan to add many Issues to their repository, unless any seemed truly missing, warranted, and meet the criteria for being added there. In the unknown event that they dislike me doing that (although other GitHub users have added Issues there and GBIF admin implied I could as well), one way to reduce me from adding iNat Issues would be for the iNat admin to add the corresponding applicable missing Issues there themselves first.

Also, I promise to (continue to) always speak appropriately and neutrally, and (as I told GBIF/COL and they understood, and once years ago told iNat admin on their own website), the Issues or Requests I make aren't demands or complaints, so shouldn't be regarded, mischaracterized, or dismissed as such. I specifically have always caveated that even in seemingly clearcut Issues to solve (e.g., known iNat website bugs that I personally helped document), that I'm writing about them to document them and to suggest that they be fixed if and when possible. I.e., I'm aware and taking into consideration time, priority, and resource limitations and constraints, and that in some cases Issues can't or won't be solved quickly or possibly ever (but for Issues claimed to be impossible to fix, I'd prefer to have a longer, specific discussion over verifying if that's certain).

For e.g., in my first existing iNat Issue linked to above, I noted that GBIF and iNat benefit from their mutually agreed upon iNat RG records synchronization, but that what seems to have happened is that iNat later added "infraranks" like subgenera, possibly without asking or consulting GBIF about what that would result in, and that it caused a problem: subgenus records are displaying as genera records on GBIF. So (if my inference of what
happened is correct or mostly so), especially for Issues like that, that even seems more like an obligation of iNat admin having a discussion with GBIF admin, hypothetically even if I'd never been involved or brought it up. iNat is continuing to benefit from the GBIF-RG synchronization, but this problem is large and can result in authors publishing on incorrect data. Overall, and I'm merely tagging three iNat members who I've communicated online with most, I hope that going forward on GitHub there will be iNat response to such Issues, at least in time, and at least between iNat and GBIF, but that I should also at least be informed of the outcomes so I can close the Issues.
@tiwane @loarie @kueda (etc.)

Lastly, I just now created two more missing Issues, which the above comments wouldn't (at least yet) apply to.
The first is to iNat.
The second I also thought would be to iNat, but after learning more about it may be more on GBIF's end, so I added it to GBIF (also because no iNat users have responded to any Issues I was involved in yet). Yet, this second issue, like some of the aforementioned, could be considered more of an GBIF-iNat or iNat-GBIF issue, in that it affects both websites, and could be addressed by prior communication (before making changes, or to anticipate that the problem would later occur) or by current communication between them.

Thanks all for your consideration and understanding why I wrote this comment, and that my intent is to constructively freely volunteer my time to improve your websites, so I appreciate being respected.