Is there a difference between the two observation fields “Eating” and “eats”? They both take a taxon. I suppose one could put that a banana slug “eats” mushrooms, even if it isn’t “Eating” one in a particular observation, but that seems like splitting grammatical hairs. Also, does it matter that “eats” is lowercase? It’s also a little confusing to have “Eating” and “Eating (Interaction)”, the latter of which takes a description, the former a specific taxon, but I’m not sure what the nuances are of the parenthetical interactions.
1 Like
Observation fields are user created and there are no standards for them. I believe the “(Interaction)” fields were created and are used by the southern Africa community (although anyone can use an observation field).
3 Likes
Observation fields are created by users, I believe, not staff, so there are a lot of duplicate observation fields out there.
OK that’s what I suspected. Is there then a way to delete redundant ones? Like curators can do with common names?
If they could, one would think they would start by deleting all the “non-scientific” fields. If you look at say the Gerald (https://www.inaturalist.org/observations/5890862), you will find tons of user-created fields that are not related at all to “science”. Thus, I believe the curators have no intention of getting rid of redundant fields, at least yet.
2 Likes
They’re not redundant, different fields are used for different projects, so no, they shouldn’t be deleted.
4 Likes
I discovered that curators can edit these fields (https://www.inaturalist.org/observation_fields). Why can’t “eats” and “Eating” be merged? Looking at the observations, they serve the same function. For what it’s worth, “Eating” has over 12,000 observations and “eats” has fewer than 15.
I agree, they shouldn’t be deleted. Annotations were created as a way to make certain fields “more consistent”, and when you set any of the relevant fields at upload, the associated annotation gets set as well. For example, the lifestage annotation might get set of you include the fields “egg”, “eggs”, “number of eggs”, “eggs present”, “egg colour”, “ova”… Etc, but there is no way they should be combined because “colour”, “present” and “count” hold different data that might be relevant to specific projects.
2 Likes
Probably those two should be merged. However, do curators have all the time to go through each observation field to see if its redundant or if it’s being used for a project?
1 Like
Yeah, the “Geralds” projects proves that there is a lot of overlap.
I know I’ve seen lots of fields for scat, bones and tracks.
I’m personally against merging them.
There could be use put on those fields by the creators of them that might make merging them problematic. If you think they should be merged, then contact the creator of the field (perhaps the least used one) and suggest they could use the other one, then it would be up to them to agree to it. Even then, there might be others that have taken up the use of that field in their data use. I for one use the “accession number” field, which I didn’t create. It would be a serious aggravation to have that suddenly be changed to something else without my input on the matter! If the owner of the field decided it was prudent to do so, then so be it, but for someone else to arbitrarily think things need tidying up at my expense… no thank you!
And for what? Merging those two fields doesn’t achieve consistancy across all the other similar fields. You merge “eggs” and “egg”, but then anyone using the data still has to search for the new “egg(s)” field and “ova” as well. In fact, cutting down the duplication makes it more likely that anyone using the data is not going to notice that there is still duplication, and therefore miss a big chunk of their potential data pool.
Then there are the cases where the functionality of the fields is similar (eg “similar observation set” and “observation group”)… but there are times when having two fields to group with is actually quite handy! In the case of “eating” and “eats”, it might cater for situations where there are two prey items in a web, for example. Who knows, perhaps that is the reason the owner of the extra field created it?
The “observation fields” space is, has always been, and should remain the free-form nature that it is now. The annotations feature is the space where you can get pedantic over the wording and so on.
And don’t even get me started on the whole “Gerald” thing. I appreciate it for the humour aspect (I would wear the Gerald T-Shirt!), but when users are creating fields just so that they can increase the number of fields that are on that observation… that is taking a joke too far. This is not directed at anyone specifically, but if anyone seriously wants the “fields namespace” to be tidier, perhaps they should start with a campaign for idiots “well-intentioned sheep” to be more responsible in creating them in the first place.
@thomaseverest If it is a concern that not all relevant observations are picked up by the “eating” field, then you can always add the other one as well. Perhaps once you have done so you could contact the owner of the field and let them know you have done so, and ask them if they will consider deleting theirs… 15 observations would suggest the impact would be low. But there certainly is no harm in both fields being applied to an observation!
2 Likes
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.