iNaturalist Research Grade records are transferring to GBIF at the wrong taxonomic rank

[bdagley]

On iNaturalist observations, the Community Taxon is the taxon that becomes Research Grade and sent to GBIF, and is shown under the top section of the observation. In addition, observations display another ID at the top, which may or may not differ from the Community Taxon, but is supposed to be irrelevant with regard to Research Grade.

In this example, the community taxon is genus Nomada, since only one identifier made an ID for species Nomada vegana (https://www.inaturalist.org/observations/57562608).

But, this record is shown on GBIF as species Nomada vegana (https://www.gbif.org/occurrence/2883154460).

Note: some time ago, Complex-rank iNaturalist RG IDs were displaying as species-rank on GBIF, and some fix was made on GBIF. But it's unclear if that's related, and the current example doesn't include any Complex-rank identifications.

[bdagley]

It's possible that this issue or bug is on the end of inaturalist, since the wrong taxon is made RG on the inaturalist record when veiwed on the inaturalist, but I'm also just noting it here. Another inaturalist contributor is also going to mention this to inaturalist.

[ManonGros]

@bdagley It looks like iNaturalist kept the species name. This is what is provided to GBIF but also what is displayed on the iNaturalist observation page:

Maybe that's a question to @kueda from iNaturalist

[bdagley]

Yes, I and the other user who was the first one to notice this concluded that it's occurring on the inaturalist website. While this discussion has been opened, I also noticed another recent Research Grade bug, shown here: https://www.inaturalist.org/observations/165272978.

[bdagley]

Currently at least, there no longer is a community taxon/research grade error on those pages.

[bdagley]

My mistake in closing this Issue. The second example I'd posted is currently fixed, but the first example still isn't fixed (https://www.inaturalist.org/observations/57562608). Also, would it be possible to transfer this issue to the iNaturalist GitHub page? And in general, if properly documenting an issue, is it okay for us to post directly to the iNaturalist GitHub? (so far only iNaturalist staff members and their developers seem to have done so). I don't use the iNaturalist forum and find GitHub more effective for documenting and solving these issues.

[ManonGros]

As far as I can see, iNaturalist has a GitHub repository: https://github.com/inaturalist/inaturalist/issues but issues can't be transferred between repositories that are owned by different organisations. A new issue would have to be opened.

[bdagley]

Okay, I'll leave this one here for now, although may close it and add a duplicate one in there later on in the event the issue doesn't become fixed or receive comments on here.

[bdagley]

I'm still looking into this. For the first issue mentioned here (in the title), I previously said it seemed fixed. For the second issue I also mentioned on this page, I'm currently slightly unsure but it seems like it may have been fixed as well. This is the link to that page on inaturalist: https://www.inaturalist.org/observations/165272978.

Can anyone from inaturalist (@kueda didn't reply so far to the December tag by @ManonGros ) or GBIF verify if either issue is truly fixed, and how? For example, if a fix was made, or if these bugs got fixed on their own somehow? Doing so would also allow me to eventually close this Issue.

[bdagley]

In the future, ideally iNaturalist members including @kueda will consider replying to iNaturalist-related discussions like this. I so far have only somewhat rarely posted on GitHub, and very rarely posted about iNaturalist-related issues.

Anyway, it seems the things mentioned in this Issue are no longer a problem, so I'll close this Issue.

[bdagley]

I'm re-opening this issue until getting confirmation of whether it's fixed, based on the discussion in this related issue.

[ManonGros]

This particular occurrence is no longer research-grade and therefore, it is no longer available on GBIF.

[bdagley]

I gave at least two links above. One observation/occurrence record seems to have been deleted (unsure on which site) and the other is not currently research grade as you mentioned, if this was the one you referred to (https://www.inaturalist.org/observations/57562608).

The additional, still-open Issue on the inaturalist repository was about the wrong inat. ID rank of records being sent to GBIF, since the inat. community ID isn't sent, only the observation ID is. The current issue re: species complexes is similar but seems different. In this current issue (when it is occurring), an inat ID that has a species complex observation ID (but not the community ID, which isn't complex) is sent to GBIF as the complex ID. In the other issue, we'd expect that the inat complex ID actually would be what would be sent to GBIF (even if still incorrect). So, there seems to be at least two kinds of ways in which wrong inat ID/records are being sent to GBIF. It's unclear to me if the current issue is fixed, although the additional one is known not to be fixed yet. If anyone can confirm/show how either issue is fixed in the future, I'll close these issues. I've had trouble getting reply from inat. and it seems like the other related issue won't be fixed for a long time. Maybe other people will have better luck discussing these issues with inat.

[bdagley]

This issue is fairly well stated, although includes multiple issues. As mentioned by jwidness and I, loarie and jwidness already made an issue about the CID not being sent to GBIF before I joined iNaturalist, here. In it, they say that ideally the CID would be sent to GBIF (in all cases). So, there would be no need for me to create Forum post, if that's already the staff's view, which I share. They also refer to it as an "issue," and seem to indicate that some bug-like issues or seeming bugs can be documented to discuss here, not merely the definition of bugs you used.

I do consider the issue that an obs. with a species obs. ID but with only a subgenus or genus CID are sent to GBIF as a (big) issue, and at least bug-like if not a bug. Because the GBIF occurrence record doesn't represent the iNat CID of the record, which even the staff agree is the most accurate ID. It also doesn't represent the identifiers' intents in their IDs. For example, if someone IDs a species and I think species can't be known, I typically ID genus or subgenus and use DQA to make the obs. RG (obs. ID=species, but CID=genus or subgenus). My intent is not for that species record to matriculate to GBIF.

I also linked to the related issue where species complex IDs were transferring to GBIF as species-rank IDs. Matthias considered that a big problem. Do you consider the complex issue a bug, or different from the above issue?

For the Explore-related issue, setting high and low filters to species shows some records that have a CID of genus or subgenus. Part of why this is misleading is because Explore is stating that the species record exists (even on inat) and is a datapoint on the map.

Anyway, since these issues have already been raised here, including at least partly by the staff previously, and the staff and devs are aware of the issues, it would be ideal to continue to document or discuss them somehow, whether or not the issues were to be merged into a single issue page or something. Otherwise people will just forget. The key point (that the staff agree on) is that only using the CID makes sense re: GBIF, and I added that the Explore situation can be misleading and might also ideally be changed to use the CID. Lastly, I won't use the forum at all, but I and others have noticed in the past that many issues like this don't get discussed there, especially by staff or devs. So, I would hope this gets looked into in time, including if it's more of a discussion among the staff and devs about making website changes to address these data issues, regardless of whether you consider them bugs.

[jwidness]

Just to clarify, I am not iNat staff and I don't speak for iNat staff. My opinions are my own.

[bdagley]

I was implying that staff members loarie (in the github issue) and tiwane (in the forum request) seemed to agree with the suggestion that the CID is most accurate and should ideally be sent to GBIF, etc.