# Thoughts on dealing with imported subfamilies, tribes etc

**URL:** <https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523>\
**Category:** Curators\
**Created:** [July 17, 2020, 4:51pm UTC](https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523 "2020-07-17T16:51:59Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![cmcheatle](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.inaturalist.org/cmcheatle/32/37_2.png) [@cmcheatle](https://forum.inaturalist.org/u/cmcheatle)\
**Post date:** [July 17, 2020, 4:51pm UTC](https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523/1 "2020-07-17T16:51:59Z")

</div>

Increasingly it seems like more and more of these are getting imported by users using the external imports tools. When they show up in the ungrafted taxa list, I am curious what approach other curators feel should be taken.

Guidance on these less official node levels in the curator guide can I think be best called as cautious, leaning towards preferring against their use :

- if you graft them into place, they just end up as orphans, nothing moves under them. It can be a huge task to populate them, even worse if someone imports subfamility X, but it turns out subfamilies Y,Z, A, B, C and D also exist
- set them as inactive, which will inevitably lead to flags about why did you set my subfamily inactive, it is a perfectly valid name.
- other ?

---

<div class="post-metadata">

**Author:** ![choess](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.inaturalist.org/choess/32/2433_2.png) [@choess](https://forum.inaturalist.org/u/choess)\
**Post date:** [July 17, 2020, 6:42pm UTC](https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523/2 "2020-07-17T18:42:17Z")

</div>

I generally take the first approach–graft them in place, and if I have time and understanding to work it out, try to move some or all of the correct genera. The major failure cases here are people following the taxon, or using it in identification filters, and not capturing some observations due to genera not being moved; or identification disagreements getting bumped up to a higher level. But people making use of subfamilies and tribes are likely to have a good grasp of the taxonomy on that branch of the tree, and this will presumably help bring it to their eyes and encourage them to fix it, so I think it’s preferable to suppressing those ranks.

---

<div class="post-metadata">

**Author:** ![cmcheatle](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.inaturalist.org/cmcheatle/32/37_2.png) [@cmcheatle](https://forum.inaturalist.org/u/cmcheatle)\
**Post date:** [July 17, 2020, 7:06pm UTC](https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523/3 "2020-07-17T19:06:51Z")

</div>

> [@choess](#):
>
> try to move some or all of the correct genera

That on is kind of the biggest hurdle in my view. The curator guide is pretty clear that we should adopt an all or none approach, ie don’t start what you can’t finish.

Specifically it says ‘If you want to add additional nodes to a tree make sure you are willing and able to spend the time ensuring that all nodes globally that should be included in that node are grafted as descendants.’

And further ‘As a rule of thumb, not including additional nodes in iNaturalist is preferable to including but only partially curating additional nodes as in the middle tree above.’

---

<div class="post-metadata">

**Author:** ![choess](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.inaturalist.org/choess/32/2433_2.png) [@choess](https://forum.inaturalist.org/u/choess)\
**Post date:** [July 17, 2020, 7:56pm UTC](https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523/4 "2020-07-17T19:56:03Z")

</div>

I had taken that as a directive on curators _importing_ new taxa–don’t deliberately import intermediate levels of classification unless you’re willing to populate them. OTOH, once they’ve already been pulled into the database, I think a partial fix is better than none.

---

<div class="post-metadata">

**Author:** ![jwidness](https://avatars.discourse-cdn.com/v4/letter/j/9d8465/32.png) [@jwidness](https://forum.inaturalist.org/u/jwidness)\
**Post date:** [July 17, 2020, 9:31pm UTC](https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523/5 "2020-07-17T21:31:12Z")

</div>

If I find an ungrafted mid-level taxon, I might graft it in if:

- I can find reasonable taxonomic support for it (so not just some guy’s blog)
- there’s a comprehensive source describing everything that should be under it
- it seems like people actually use it, like for some of the really big insect clades

Otherwise I’m likely to just leave it alone or to flag it for someone else’s opinion.

> [@cmcheatle](#):
>
> even worse if someone imports subfamility X, but it turns out subfamilies Y,Z, A, B, C and D also exist

I guess I don’t see this as a huge problem as long as everything that belongs under X gets moved to X. So this doesn’t really bother me:

Tribe X (Genus 1, Genus 2, Genus 3)  
Genus 4 (belongs to Tribe Y, but iNat doesn’t have Y)  
Genus 5 (belongs to Tribe A, but iNat doesn’t have A)

---

<div class="post-metadata">

**Author:** ![pulk](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.inaturalist.org/pulk/32/25509_2.png) [@pulk](https://forum.inaturalist.org/u/pulk)\
**Post date:** [April 19, 2022, 5:48pm UTC](https://forum.inaturalist.org/t/thoughts-on-dealing-with-imported-subfamilies-tribes-etc/14523/6 "2022-04-19T17:48:22Z")

</div>

Glad I found this conversation! It’s almost 2 years old, but it still seems important to resolve. It’s what I headed to the forum today to look for - @kitty12 informed me, on a flag on a name I added, about the relevant iNat guidelines and I was surprised/disturbed to see their current state. This is a more complex problem than I thought at first, and it has taken me a while to figure out how to explain my intuition. I don’t think we can’t resolve what’s best here with any one “here’s a bad outcome that can happen with the rule” or “here’s a bad outcome that can happen without the rule”.

The guidelines as currently written **are** clear about how they want us to handle this situation:

> [@On another topic](https://forum.inaturalist.org/t/1/1):
>
> As a rule of thumb, not including additional nodes in iNaturalist is preferable to including but only partially curating additional nodes as in the middle tree above… If during your curation you encounter partially curated nodes, it may be preferable to remove them rather than to fully curate around them if it is not possible or practical to fully curate them.

In other words: for extra-KPCOFGS taxa, when the options are **removing/not adding the taxon** and **having the taxon, but without all existing iNat subtaxa being grafted on** , a curator is to choose the former. Why? The explanation in the Guide is (pretty much only) this, which I’ll call Scenario 1:

> [@On another topic](https://forum.inaturalist.org/t/1/1):
>
> For example, if user A identified an observation as “Tribe Persoonieae” and user B subsequently identified it as “Genus _Garnieria_”, user B’s intention was likely to agree with user A while offering a more refined ID. But if the tree were structured as above, user B’s identification would be treated as a disagreement with user A.

The tl;dr of my reaction is this:  
**Prohibiting (any) useful names for (any) period means permanently losing out on valuable knowledge/information that IDs using those names would have provided. Most affected observations will be, permanently, that much less precise/accurate. It’s well worth the price of having unnecessarily imprecise (_not inaccurate_) observation titles for that period. As the names are eventually completed, observation titles are automatically made (perfectly) precise and (perfectly) accurate by iNat. An identifier who was denied access to the name before probably isn’t going to come back to re-identify this observation when the name is finally added.**

* * *

The too-long version of my reaction is this:

We have to acknowledge that _eventually, all of these names (that meet other criteria for inclusion) WILL be added to iNat, with all their subtaxa grafted._ If it’s a valid, useful taxon, eventually someone or some people will have the time and effort to add it and graft on all of its subtaxa.

So, let’s compare “illegal” (the current rules; incompletely subtaxified extra-KPCOFGS names are illegal; the curator wouldn’t add the name at all) and “legal” (the proposed rules; incompletely subtaxified extra-KPCOFGS names are legal; the curator would add the name but leave it incompletely subtaxified).

Let’s look at Scenario 1 from above, which is supposed to be likely/bad enough that we can’t allow it to happen. In reality, genus _Garnieria_ is a member of tribe _Persooniae_, which is a member of family _Proteaceae_. Genus _Garnieria_ and family _Proteaceae_ are already on iNat, and a curator who’s short on time is deciding whether to add tribe _Persooniae_, under family _Proteaceae_ (but neglect to graft on genus _Garnieria_, for the time being), or not to add tribe _Persooniae_ at all.

On one particular observation, user A would like to propose tribe _Persooniae_; user B would like to propose genus _Garnieria_. Would A’s tribe proposal be a confirming or disagreeing ID with B’s genus proposal? A proposes first, so won’t be clarifying it to iNat, but we can consider both intentions and look at the cons resulting from the current and proposed rules.

Under “illegal” (the current rules):

- Scenario 1a. A’s tribe _Persooniae_ would be meant to confirm B’s genus _Garnieria_.

- Scenario 1b. A’s tribe _Persooniae_ would be meant to disagree with B’s genus _Garnieria_.

Under “legal” (the proposed rules):

- Scenario 1a. A’s tribe _Persooniae_ would be meant to confirm B’s genus _Garnieria_.

- Scenario 1b. A’s tribe _Persooniae_ would be meant to disagree with B’s genus _Garnieria_.

It seems to me that in both scenarios, the “legal” outcome is better. Yes, the observation will get a unnecessarily, significantly (Scenario 1a) or moderately (Scenario 1b) less precise title **for the time being**. But that title is on the basis of more, valuable information, which is now being preserved, and _will_ be immediately, properly, automatically taken into account and reflected in the observation title, as soon as tribe _Persooniae_ is fully subtaxified. Which we know _will_ happen. Not only will it happen, but **it will happen sooner if it can be done piecemeal than if it has to be done all at once**. Any of us curators can find 2 half-hour periods to work on iNat taxonomy in a shorter span than we can find 1 hour-long period. Let’s not let the perfect be the enemy of the good, and add the name now, and work on integrating it as time goes on.

By the way, we should keep in mind this scenario was cherry-picked to showcase the “worst” of the “legal” protocol. A perhaps equally (more?) common scenario would be

- Scenario 2. User A wants to propose tribe _Persooniae_. There is no user B who looks at this observation. Under “illegal”, A can’t do it and has to settle for family _Proteaceae_. Under “legal”, A can do it. Simple.

I’m really curious to hear others’ thoughts on the issue in these terms, because despite this wall of text, it really seems like a no-brainer to me. Collect as much valuable information as possible, and don’t reject it just because it makes the interim display less pretty (less precise, not less accurate). I come to this from the context of Mushroom Observer users importing our observations en masse and adding the extra-KPCOFGS names we’ve used there, here, not wanting to throw away the precious information contained in those IDs. But I think it applies equally to any curator adding names.
