Skip to content

participating_taxa named by CURIE is ambiguous in exactly the records that need it most #524

Description

@realmarcin

Found while implementing #312 in PR (participating_taxa on EcologicalInteraction). Not a defect in that PR — a property of the data that curators need to know before using the new slot, and one I only found by running it.

participating_taxa entries resolve the same way source_taxon/target_taxon do: by preferred_term, by term.label, or by term.id. The id path is necessary — a participant named only by CURIE is still a participant — but in strain-level records it does not identify a member.

Measured on the worked example. GLBRC_Populus_Variovorax_SynCom28 has 28 taxa and exactly 1 distinct NCBITaxon id (NCBITaxon:34072, Variovorax): 28 strains of one genus. Naming two participants by preferred_term narrows connectivity credit correctly — 26 members become DISCONNECTED. Naming the same two by CURIE credits all 28, because the CURIE cannot distinguish them.

Both behaviours are right. taxonomy_keys_by_id maps one id to all 28 keys, and crediting all of them is the only sound reading of an ambiguous reference.

Why it matters: the whole point of participating_taxa is to narrow an over-broad credit. A curator who reaches for it in a SynCom — which is precisely where the all-or-nothing credit hurts, since those records carry many near-identical members — and who names participants by the id they see in taxonomy will get no narrowing at all, with no warning. The slot will appear to do nothing.

Handled in the PR by documenting it on the slot and pinning both behaviours in tests/test_participating_taxa.py, so the ambiguity is a recorded property rather than a surprise.

Not done, worth deciding: should the auditor warn when a participating_taxa entry resolves to more than one member? That would catch the silent-no-op case at the moment it is written. Against it: an id resolving to several members is legitimate when the statement really is about all of them, so the warning would fire on correct records too. It probably wants to be conditional on the entry carrying only an id and no preferred_term — that combination is much more likely to be a mistake than a choice.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions