I agree with the intent of this and sometimes wish there were more thought put into this specific issue. I think the difficulty here might be… what happens when the parent observation is deleted?
The interactions OBS fields refer to a taxon… a taxon that wouldn’t be deleted (or is less likely to be). The problem is… storing that taxon data with every (in many cases) hierarchical interactions leads to the Garald-ification of any observation of an interacition. Why store the taxon every single time?
Example hierarchy…
name of associated plant
interaction → visited flower of
nectar / pollen delivering plant
nectar plant
pollen delivering plant
These hierarchies are the only way to capture all the information for the interaction that satisfies the aggregate (what taxon was the observed taxon on? And the granular… (what taxon was the observed taxon executing this particular interaction with)?
If a “found on” taxon were collected as a “core” iNat observation field (like annotations that are always available to be captured)… the interactions could be captured in a drop-down list of simple name/value pairs (or better yet… a multi-select). This is because the people only interested in the granular would be asked to capture the “found on” before choosing the more granular interaction.
As it stands, the above hierarchy would be modeled by storing all the data for a single redundant taxon five times on that observation. These five mirrored instances of the taxon data would then be returned by the observations endpoint up to 200 times. At least that’s my understanding.
The other way would be to only return the field_id and field_name for the observation fields of type taxon that have matching values. it would break a lot of downstream logic but could be an option with a default on the API interface.