Merging "Host Plant" and "Host Plant ID" fields

Dropping this here because I want to make sure it isn’t a mistake before I commit. These two fields appear identical to me and that different projects and people use one or the other means that there’s a lot of work applying both to every observation. It seems like a waste of everyone’s time, they even share the same field description.

6 Likes

I think this would be great! (But I’m not a curator.)

2 Likes

I haven’t worked with merging fields before, but the yellow warning message gives me pause. If criteria for membership in a project happen to depend on the field that is being merged, will this break the project? Or will both the project criteria and the observations be updated to the field that is being kept? I don’t know the answer.

3 Likes

Maybe there’s a way to see what would happen with some test project/fields?

1 Like

I generally think this is a good idea as I imagine that there may also be some confusion between new users picking the wrong field of the two and not having their observations enter the project that they wanted. So the merge could benefit all projects in the long run.

Although, it might make sense to “keep” the “Host Plant ID” field as opposed to the “Host plant” field as it has almost double the number of observations and more projects (22 vs. 16). This would mean fewer observations/projects would have to change, etc. (if things aren’t automatic).

5 Likes

That’s what I want to know. Will it replace all the use of the merged field with the retained field, in project rules, and on people’s observations? Is it going to break if people had both fields added, and they become merged?

I think you only need 4-6 fields in total and all the others should be discontinued…otherwise others can add the field again the other day. If a project is filtering smarter much much more additional descriptive data will come available as there are only 4 fields to convert in stead of 40.000.

How are the numbers/occurances of the “Host” fields ? I think using the same photo (press ‘i’ to see related observations) and using the genus name would point out the relation. Just point out there is an relation “in relation with”
image

There’s also one called “Insect Host Plant” and one simply called “Host”. Personally, I like “Host”. It’s simple and encompasses insects, fungi, etc… and works for animal and plant hosts alike. Right now, I find myself adding this host thing several times to an observation just so it conforms to some project. Will merging them break a project? Maybe. I would try it with a couple of dummy projects and two new dummy fields like Host Field X and Host Field Y and see what happens.

6 Likes

This is actually a broad problem that I’ve noticed with many of the observation fields on iNaturalist. There appear to be a lot of categories that are duplicates, and it’s not always clear which fields refer to which. For example, regarding predator/prey interactions, I’ve noticed at least eleven categories which refer to the identity of the predating taxa, including:
“Predating”
“Predator Taxon”
“Predator of Odonate”
“Predator Species”
“Predator Identity”
“Predator”
“Interaction->attempted predation by”
“Interaction->attempted predation on”
“Interaction->preyed on”
“Preying on”
“Preyed Upon”

And then at least five regarding the identity of the taxon being preyed upon:
“Prey”
“Preying On”
“Interaction->Preyed upon by”
“Prey ID”
“Prey Species”

These aren’t the only examples, I’ve noticed many other categories such as “phenotype” are duplicated or are defined to only refer to specific species (e.g., the actual field “Phenotype” seemingly only records whether individuals of Sciurus carolinensis exhibit melanistic or wild-type coloration). In that case it’s a bit more understandable as not all taxa exhibit the same phenotypic variation, but it’s very confusing if a user wishes to log unusual phenotypic patterns like leucisism, albinism, melanistic, or schizochroic color patterns (or document variation within a highly variable species).

5 Likes

As much as I’d like to make dummy fields to experiment with this, a staff response would be worthwhile!

1 Like

Also at least 5 for roadkill.

3 Likes

Just to be clear, site staff have previously indicated, and I am unaware of any change in their thinking that they will not take any steps to merge, standardize or otherwise manage observation fields.

1 Like

At least on my end, that’s not what I’m asking, really. It doesn’t require staff to hit the “merge” button. But I’m asking if merging fields is going to cause the problems listed above, which would be extremely inconvenient to resolve.

3 Likes

The point I was trying to make is if there are issues or problems that come up with trying to do this, the site is not going to allocate any effort to the code changes needed to resolve them.

Is it not possible to discontinue a field like “road kill” and add it to an annotation like https://forum.inaturalist.org/t/new-annotation-evidence-of-presence/23945/13. “Evidence of presence” is that a sort of “Appearance”?

==

Instead of Dead one could add Dead-Roadkill

Unless it is a “roadkill” annotation it won’t exclude other observations, it’s “dead”+”organism” and that fit all dead ones.

1 Like

Having the observation specifically be labelled as roadkill can also be useful for natural history or conservation processes. I.e., if a threatened species keeps turning up in iNat a lot (potentially disproportionate to its expected observances), it may be evidence of a broader issue. I know in the case of wood turtles (Glyptemys insculpta) in Michigan local populations got wiped out due to roadkill, and some turtle specialists would have definitely appreciated if such a thing was flagged in iNaturalist.

3 Likes

I tried it with 2 test observation fields and a test project. There’s an error (translation missing: en.you_cant_merge_observation_fields_in_use_by_projects) that prevents you from merging one if it’s used by a project, required or not. You can merge it if it isn’t used by a project, but when the changes are applied to observations they seem pretty glitchy (e.g. it sometimes goes invisible on an observation instead of converting).
Unfortunate, because even if staff don’t want to manage fields that doesn’t mean in theory curators couldn’t. The mechanisms are set up for that to be possible but they don’t seem to work…

3 Likes

ah, it should not be the field “Appearance” but the next
"List Of Values"
Dead,
Dead by Roadkill
“Alive”
“Can not be determined”
In my opinion you should not have more than 5 fields in total so merge as much as possible.

1 Like

Yes, it would be cool if under dead annotation we could choose cause of death as in observation field! Ans with alive it’d be like “seen on photo” or “seen, but not captured” for tracks/feathers.