I’m always a bit hesitant to suggest that researchers, land managers, or other folks use iNaturalist observation fields to collect associated data because anyone can edit the observation fields on other users’ observations.
In the past I’ve experienced people adding (hundreds of) unwanted and often inaccurate observation fields and editing existing observation fields. As a result, I don’t use this feature very much and I have opted out of people adding new observation fields. :( But it would be great if edits to my observation fields could be locked so that I can feel safer that any data I collected won’t be modified or erased. Even better might be an expansion of the Relationships feature, where I could trust certain people to add/edit observation fields or add my observations to relevant projects.
Added a host plant ID with main account:
Logged into test account and changed the host plant to a different species:
Edit saved successfully:
(There is also a “bug”/unexpected event, where the delete option is presented to other users, but it does nothing and no error is provided to indicate that the field was not actually deleted.)
Desired change: remove Edit and Delete options for other users or untrusted accounts.
I have mixed feelings about this request. On one hand. I want to preserve the data of the observer. On the other hand, community input is one of the great strengths of iNat. Where’s the harm in letting the community correct the host plant ID. Well… when they get it wrong because the photo is a random background plant and not the host or someone just makes their own error or corrupts the original intent to make the observation fit their own project needs.
And on the third hand ([checks] dang, I only have 2 hands), what if the land manager is adding annotations to other observers’ records to aid management needs? Locking out the community will also lock out the land manager.
Probably the best option for professional users is to participate in the iNat community, harvest data as needed, but keep an agency database for official use.
I can definitely see the locking of editing or deleting fields being useful, and I would support that.
I would, however, not want to see other users totally prevented/blocked from adding their own observation fields. I could see a scenario in which someone was wanting to look at all the observations of a species or group of observations and add some kind of field to them for a research project, etc. (though I haven’t ever done that myself). Preventing others from adding their own fields seems like it might have the potential to inhibit use of the data. Also, the negative impact of extra fields from users who aren’t the observer seems smaller to me than the loss/change of data by the observer (though happy to learn otherwise).
yikes. I didn’t even realise my observation fields could be modified by other users. guess I’ll start putting that info in the description so it doesn’t have the possibility of being lost.
Personally, I’d rather see this added to the list of things that you are notified about, rather than locking users out. I think we should be striving to minimize the number of things that users unilaterally control.
I partly agree with this because users opting out of the community taxon sometimes seems counter-intuitive and can be quite frustrating with incorrect ID’s, but observation fields seem to have a more personal user-specific place than the ID of the organism itself. I don’t know much about the link between projects and observation fields, but I feel that if project curators are able to remove observations from their project based on an erroneous association, then it shouldn’t be much of an issue in regards to the function and usefulness of the site.
Voted YES. I’d lead the parade to disallow anyone to edit my obs fields!. Had no idea that this was even possible. I use those fields for my own research specifically; and that data is also incorporated into another site. Its integrity is paramount to me. It is MY choice.
I’ve always opted out of allowing new fields unless they were project curators. Occasionally I’ve been asked to add a field (and sometimes even the content for that field) for a researcher’s specific purpose and been happy to do so. In the same fashion professional users have messaged or emailed me for specific data which, again, I’ve been happy to supply.
Ditto…horrifying! Initially I searched diligently for existing fields to use, and rarely found any with suitable values for my research. I read on this forum that the initial attempt to standardise and limit field creation had been abandoned, replaced in that function by Annotations, and Fields had been left for individual use as needed by users.
So I have let rip. Especially as it is a feature that can be added in bulk editing, searched on using urls which can be placed in reports etc, it has become integral to the use of my observation data, and on occasion when I have had to edit even one character of one field value I have to spend hours correcting my earlier uses of the Field.
So I would be devastated to find a Field I have created had been edited…especially if I did NOT discover it, and the observation search results linked to my reports changed.
If someone else uses a Field I have created those Search results can be filtered out by Place or Project or user. But if they edited the Field name or Value…wow. Are you sure that’s possible?
Perhaps field values could work the same way as IDs work at the moment. The owner of an observation could provide their value and other iNaturalist users could also suggest values for the field. It would be up to users of the data to decide how they preferred to work with the information provided by others and the data provided by specific users could not be destroyed by others.
Exactly. When I upload eg an invertebrate, whose life stages I am interested to learn but pretty much ignorant of, I often add a life stasge field and a guess, or unknown if that is an option, in hopes of expert correction. However, I use other fields in a way peculiar to my own active projects, which no one else would be familiar with, so those I would not want changed.
As long as the default is “Anyone” thus making the decision to disallow adding observation fields an “opt in” choice. I worked with my students on having them add observation fields for the local language names of their plants in these islands along with ethnobotanical uses, but most of my students operate from the app where the observation fields are not available to them. So I instruct my students to enter this information in the description field in the app, and then I can later transfer their entry to the appropriate observation field from the desktop interface. I am able to do this only as long as the default for a new account is the ability to add observation fields.
I would support bundling and rephrasing the current to “Allow Adding and Editing Observation Fields from” so users clearly know what they are agreeing or disagreeing to accept.
Question please. Originally if I allowed project curators to add observation fields it applied to traditional projects that I specifically joined. With the advent of Collection Projects, are those administrators also considered project curators with the same ability to add fields?
