Ancestor disagreement shouldn't necessarily disagree with child taxon just because it contains descendant

Feature Requests
17

So far, I mentioned only explicit disagreements, when the identifier answers ‘No’ to this question:

image
image917×316 60.6 KB

I said nothing about other disagreements (hence your question), because with regard to the algorithm it’s just about adding an ID in conflict with the previous ID, and this is treated exactly in the same way as adding an ID in agreement with the previous ID.

Apart from a case of explicit disagreement, whether 2 IDs agree or not does not count when computing the CT: each ID contributes as +1 for a taxon and for all its ancestors, and that’s it. The small print saying it’s a disagreement is just an extra reminder. The CT is computed without considering if the 2 IDs agree or disagree.

Illustration. We say that Acacia and Mimosa disagree. We say that Acacia and Mimosoideae agree. But for computing the CT, it’s just the same, just 2 IDs, each with +1 contributions:

  • Acacia + Mimosa result in count 1 for Acacia, Mimosa, Mimoseae, and count 2 for Mimosoideae and all its ancestors,
  • Acacia + Mimosoideae result in count 1 for Acacia and count 2 for Mimosoideae and all its ancestors,
  • no need to consider that Acacia and Mimosa disagree, or to consider that Acacia and Mimosoideae agree to perform the computation, we simply count +1 for each taxon and all its ancestors, in all these cases.

Illustration with explicit disagreement. Alice says it’s Acacia. Bob says it’s Mimosoidea but also that it’s not Acacia. For computing the CT, it’s not the same as just 2 IDs, because the disagreement is an additional input from the identifier and the algorithm has to deal with it. It results in count 0 for Acacia, and count 1 for Mimosoideae and all its ancestors. The disagreement here is computed explicitely: +1 for Acacia and all its ancestors, +1 for Mimosoideae and all its ancestors but also -1 for Acacia and all its ancestors.

Example 6 (RG observation receiving a 3rd different ID):

  • add an ID Senna tora,
  • add an ID Senna tora,
  • add an ID Senna obtusifolia, count 2 for Senna tora, count 1 for Senna obtusifolia, count 3 for Genus Senna and all its ancestors, so CT is Senna tora, finest rank with score 0.67 = count 2 / highest count 3,
  • but if we prefer more than 2/3 as the rule, CT would be Genus Senna, finest rank with score 1 = count 3 / highest count 3.

Example 7 (with different ranks):

  • add an ID Senna tora,
  • add an ID Senna tora,
  • add an ID Genus Chamaecrista, count 2 for Senna tora and Genus Senna, count 1 for Genus Chamaecrista, count 3 for Subtribe Cassiinae and all its ancestors, so CT is Senna tora, finest rank with score 0.67 = count 2 / highest count 3,
  • but if we prefer more than 2/3 as the rule, CT would be Subtribe Cassiinae, finest rank with score 1 = count 3 / highest count 3.

Example 8 (with more agreeing IDs):

  • add an ID Senna tora,
  • add an ID Senna tora,
  • add an ID Senna tora,
  • add an ID Genus Chamaecrista (Maverick), count 3 for Senna tora and Genus Senna, count 1 for Genus Chamaecrista, count 4 for Subtribe Cassiinae and all its ancestors, so CT is Senna tora, finest rank with score 0.75 = count 3 / highest count 4.

It’s possible to tune the algorithm by changing the score threshold that determines the CT. I suggested at least 2/3 (by inattention, and I regret this unnecessary change) instead of more than 2/3 as it is in the present iNat algorithm. I am OK with the common ancestor being the CT of 2 + 1 IDs, no need to change that.

My intention is to change the behavior in case of explicit disagreement, in order to make the observation easier to find and to reduce the identifiers workload before the CT reaches the rank species.

We should keep in mind that there is an Observation Taxon and a Community Taxon.

Identifier in search for observations to ID:
When I search for Fabaceae observations with the URL https://www.inaturalist.org/observations?taxon_id=47122 I target the Observation Taxon (not the Community Taxon) (see here). So, my true target (attempting to help identifiers find observations) is the Observation Taxon. But iNat’s detailed explanations in the popup “What’s this?” are about the Community Taxon, so I talked about the Community Taxon in my proposal.

Identification work completed (provided the ID is correct):
When an observation becomes RG, are the Observation Taxon and the Community Taxon the same?