I suggested removing these criterion from the Research Grade Qualification because they become redundant with the addition of “Export taxon exists” to the RG Qualification. As proposed, an observation’s export taxon is null unless/until a community taxon exists (which itself requires more than one ID) and it agrees (at least at some rank) with the observation taxon.
One thing I had floating around my head but failed to articulate about the export taxon is that the community taxon should have more than 2/3rds agreement in order to inform the value of the export. This would ensure that observations continue to not go to GBIF until they “Ha[ve] ID supported by two or more”.
I don’t consider the timeliness of data going to GBIF particularly problematic. It just came to mind as a knock-on effect of this proposed design. In most cases, I think things are fine. However, there are lots of times I’ve noticed something sitting at genus or complex for years (with multiple IDs at that same rank) and nobody wants to add (or keep) a species-level ID or mark it as not possible of being ID’d further. Again though, as I mentioned in my original post, if we feel like this would “open the floodgates”, a narrower threshold could be defined. The key point here is the export taxon concept and the things that allows us to do.
With this proposal, the export taxon merely records the taxon that we’d send to GBIF if the observation is otherwise Research Grade (has photos, location, is of an organism, etc.). If that’s a little confusing, the two could be aligned a little further and “otherwise meets Research Grade Qualifications” could be added to the evaluation of whether to populate the export taxon.
I get that you’re not buying into the idea, but what I don’t understand fully is why. It does indeed add some complexity (an additional operation whenever an ID is saved, some additional conceptual overhead for users potentially, potential re-indexing), but I’m not sure how it doesn’t address “the original issue(s)”.
In your mind, what are the original issue(s) that my proposal was intended to address? In my mind the core issue is that the current design conflates two distinct questions – “should this go to GBIF” and “does this need further identification” – and the practical side effects that conflation has – such as conflicts surrounding sub/infra-species identification, incentives to not mark something as cultivated, to engage in certain behaviors merely to get something to achieve research grade, etc.
This isn’t a work-around, this is the fix. If the issue is a conflation of two disctinct things, the fix to that should be a (clearer) separation of those two distinct things, no? The things we’ve seen and continue to see discussed (making things behave differently once they reach species rank, etc.) are what are the work-arounds.
I think the idea of just exporting the CID instead is a fair one. However, a separate export taxon entity respects the Community ID Opt-Out choice and continues to provide the observer with a measure of control of how their data gets contributed to GBIF.
I agree that this has the potential to be very confusing. I think a well-thought out implementation within the UI could go a long way to mitigate the risk of confusion. I purposely refrained from going into detail on that though as I didn’t want people to get hung up on details that, while important, are secondary to the core proposal here.