Help with complex taxon split

Hi all, I became a curator earlier this year to work on the very messy Staphylinidae backbone. I read the curator’s guide but still wasn’t sure what to do in this situation.

I’m trying to do my first taxon split, which involves moving some genera from a tribe(which has ~10,000 observations including genera with >1000) into 2 other tribes of the sub-family but retaining other genera in the original tribe. Unfortunately, none of the tribes are atlased and they have overlapping distributions anyway.

How do I best do this to minimize “inadvertent disagreements”? There are many observations only IDed to tribe, and my understanding is that the split would bump many up to the sub-family level. However, when I looked at editing the parent taxon of 1 common genus, it warned me to do a taxon split because just moving it would also cause lots of inadvertent disagreements.

I understand that I’ll have to do some clean-up either way, but what’s the least likely to cause total carnage?

2 Likes

Welcome to the forum and being a curator! It sounds like you should split the tribe to bump IDs to subfamily, avoiding unintended disagreements from moving genera to newly added tribes. Even if most tribes overlap, I would still look into any possible unique ranges, particularly in observation-dense regions.

I would recommend drafting the split and using the Analyze IDs tool to see where IDs will move. Then move the genera, but for each one open the observations with unintended disagreements in a new tab. Then commit the split. You could also split first and move genera later. That perhaps looks nicer on the observations because the higher level IDs are updated first. After everything has reindexed (might take a few hours) check your tabs to make sure there aren’t any lingering disagreements.

2 Likes

It could be worth adding atlases for the tribes and genera involved, even if you have to draw the boundaries quite broadly. If some observations occurs in a country/region where only the atlases say only one tribe is expected, then the split process should prevent those IDs from being bumped up to genus level.

I imagine you may not have comprehensive distribution data, but if there are some large areas where a tribe isn’t present, that could still reduce the unintentional disagreements.

I would suggest also making a flag (if there isn’t one already) and tagging some top IDers or experienced curators on the proposed split before you hit ‘Commit’ so they can check it looks like it will work as expected.

I’m not even saying that specifically because you are new; I think it should be a requirement that any split that affects thousands of observations should be at least briefly checked by another curator before being committed.

2 Likes

Thanks Thomas. This is the split I’m talking about, I already created a new tribe (Tachinusini) to house some of the genera but as far as I can tell the split will leave everything in the original tribe, Tachyporini.

If I understand you correctly, I’d still have to go back and manually correct each unintended disagreement regardless of whether I do the split or move the genera first, yes?

That’s a good idea but unfortunately all of the tribes being spllit out are pretty much cosmopolitan. This was a big heterogenous tribe that was finally split up into better groups but each one still has species distributed worldwide in a couple diverse genera

@wildskyflower I just created a flag, thanks for the suggestion. Hopefully someone more experienced will have an idea how to resolve things. I tagged the top IDer earlier, who is also the only other curator familiar with that group, but he says he doesn’t know how to do splits

That split will change all IDs of Trachyporini to Trachyporinae, which I think is what you want.



(Note that 1233 is only a subset of the IDs.)

1 Like

I was hoping to find a way to transfer things into the new tribes without bumping everything up to the sub-family level, because that will take a ton of manual clean-up. But good to know that I was interpreting what was going to happen correctly

the best bet is to just not do more splits and leave it as-is. Clearly this is causing a lot of disruption and it’s hard to imagine the benefit outweighs the cost to the site’s users when you could just use subspecies.

That’s why atlasing is helpful. Even if the ranges overlap in reality, the observations in particular genera on iNat may happen to be only in particular areas allowing for some automatic transfers. That could get really complicated and may not be worth the time. But it is less cleanup to reID tribes than to override/outvote IDs that should have been split.

It’s a good suggestion, but I checked the distribution of observations already on iNat and it really is almost impossible to find an area where 1 tribe is distributed and the other’s aren’t. My conversation with the other curator who knows the group is that our best bet is probably to just change the parent of each individual genus, take some time to clean up disagreements, then move the next one once the problems have been resolved.

@charlie I’m not talking about splitting off species here, these are large and easily distinguishable tribes that were previously only grouped together for convenience because no one had taken the time to revise them in decades.

2 Likes

The tribes are not atlased : you need to create the atlases first, before drafting the taxon split.
Keep in mind that the split doesn’t change directly the observations but the identifications made on the observations.

You can create atlases after drafting the split, too. That’s usually what I do because the split has a link to create the atlases.

Sorry, I thought that I was answering to @jamesraphaelsc
Yes, you can create the atlases after. You are right.
The problem is that the photo that you have added seems to show that all IDs are going to the subfamily.

Yes that’s because atlasing won’t help anything in this case, so it sounds like bumping IDs is the best option.