You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And the source never uses "co-culture", "coculture", "consortium" or "community" — not once in 55 KB. The four organisms were each tested on the same substrate, separately.
Why this is worth raising rather than fixing quietly
MicrobialCommunity is the root class, and every other record in the KB is a set of organisms that were together — a co-culture, an enrichment, a consortium, a native community. This one is a comparison of four monocultures sharing a substrate. That is a real and interesting experiment; it is just not a community.
cultivation_setup, which I have just added, describes conditions under which each member was grown individually. I have said so in notes, but a reader scanning the field will read it as the community's.
Any KG export will emit four taxa co-occurring in a community node that never co-occurred.
Options
Leave it, with the framing explicit — what I have done: notes states it is a panel and that zero interactions is consistent with that. Cheapest, and the record stays discoverable.
Model panels as a distinct class or flag — e.g. a boolean or an EcologicalStateEnum-adjacent value meaning "members tested separately". Would let the audit and any export treat it correctly, and there may be other panel-shaped records: worth a survey of records with len(taxonomy) > 1 and ecological_interactions == [].
Remove it — it is a legitimate and well-curated record of a real experiment, so this seems wrong.
I have taken option 1 and filed this, because 2 is a schema decision and I did not want to make it inside a curation PR.
A survey worth running before deciding: how many records have multiple taxa and no interactions at all? If this is the only one, option 1 is probably enough. If there are a dozen, the KB has a record class it has not named.
Found curating it for #183. Not a defect in that record's data — a question about whether it belongs in
kb/communities/in its current shape.What the record says about itself
taxonomy: E. coli B, Eucapsis sp., Chroococcidiopsis sp. Chr20-20201027-1, Planococcus halocryophilusecological_interactions: 0And the source never uses "co-culture", "coculture", "consortium" or "community" — not once in 55 KB. The four organisms were each tested on the same substrate, separately.
Why this is worth raising rather than fixing quietly
MicrobialCommunityis the root class, and every other record in the KB is a set of organisms that were together — a co-culture, an enrichment, a consortium, a native community. This one is a comparison of four monocultures sharing a substrate. That is a real and interesting experiment; it is just not a community.The consequences are small but real:
COMMUNITY_LEVELcredit assumes a record's members are related; here they are related only by having been tested in the same paper.cultivation_setup, which I have just added, describes conditions under which each member was grown individually. I have said so innotes, but a reader scanning the field will read it as the community's.Options
notesstates it is a panel and that zero interactions is consistent with that. Cheapest, and the record stays discoverable.EcologicalStateEnum-adjacent value meaning "members tested separately". Would let the audit and any export treat it correctly, and there may be other panel-shaped records: worth a survey of records withlen(taxonomy) > 1andecological_interactions == [].I have taken option 1 and filed this, because 2 is a schema decision and I did not want to make it inside a curation PR.
A survey worth running before deciding: how many records have multiple taxa and no interactions at all? If this is the only one, option 1 is probably enough. If there are a dozen, the KB has a record class it has not named.