This field:
https://www.inaturalist.org/observation_fields/10
used to be called ‘Habitat.’ It has suddenly been replaced by ‘Type of access,’ affecting around 381,000 observations. I was sure when I got to the forum I’d find this to have already been reported. It appears I’m the first.
This is a textbook case of why it might be a good idea to standardize/freeze/disallow user access to certain observation fields, especially the most widely used ones.
This is a huge data integrity risk, and a huge wound in iNat data unless/until it’s reverted. It really shouldn’t be possible for this to happen, and it extra shouldn’t be possible for it to happen without a change log/reversion system
Today, as the “real” Habitat field has been corrupted, a user has just (inadvertently?) created a brand new duplicate Habitat field. The problems are compounding… https://www.inaturalist.org/observation_fields/22600
there are a tremendous number of observation fields that are ‘habitat’ or some minor variant/version/flavour thereof, most of them having existed for many years on iNat. I’m sceptical that the creation of this latest one was a response to the other field being edited rather than just a coincidence.
(this is not to say the editing of that other field is not a problem, I agree that this is quite bad practice by whoever did it, but I really don’t think it has compounded the problem in any way)
On that linked list, the second obs on the list is Portulaca.
In a cave ?! (unless that is an Italian word for something ?)
https://www.inaturalist.org/observations/397363721
There are a tremendous number of observation fields that include the word “habitat”, but only one whose name is “Habitat”. The creation of the new “Habitat” was only possible because the original “Habitat” was renamed to something else.
It’s been five days since this very, very significant problem began, and as far as I can tell, nothing has been done to even address it, much less remedy it. I’m at a complete loss. This is akin to a letter in the metaphorical iNat alphabet being replaced with an incorrect one, affecting literally hundreds of thousands of previous writings, and an untold number of future ones.
To be fair this was reported on a Friday after standard working hours, and Monday was a holiday in the US, so staff may have only had about an hour to look at this.
I agree that anyone being able to edit every observation field with no visible history of changes is a very serious issue though.
EDIT: While I think editing of observation fields should be restricted, I actually think that (like many other pages on iNat) the lack of a transparent history is the bigger issue. What makes a project like Wikipedia work in spite of allowing anyone to edit has always been a transparent change log. If anyone blanking a Wikipedia article meant the community had to start the article from scratch again because they had no previous versions available to revert to it would make the website completely untenable.
I’m hoping someone can help me understand an issue I recently noticed with a project I’m involved in.
I work on a project documenting ascomycete fungi in Great Smoky Mountains National Park, and while going back through our observations, I noticed that all “Habitat” observation fields appears to have been changed/replaced with “Type of Access.”
I wouldn’t necessarily have an issue with this change on my general observations, but in this particular project, habitat was an intentional and important part of our data collection protocol.
As part of the event, participants were specifically required to enter habitat details with their observations. This was not simply an optional field or something we encouraged people to provide. We made it a requirement because the observations were intended to be paired with physical fungal collections and ultimately contribute to a curated natural history collection.
The physical collections associated with these observations are being prepared for deposition in a herbarium, and we wanted the iNaturalist observations to contain high quality ecological and collection data that could remain associated with the specimens.
Part of the larger goal is to have these collections and their associated data prepared for eventual entry into the National Park Service Interior Collections Management System (ICMS), which is used to catalog museum and historical objects, natural history specimens, and archives.
Because of that, changing the field from Habitat to Type of Access creates a problem for our workflow.
Is there a way to restore or retain the original Habitat field on these observations?
Here is one of the recent “iNat Observation of the Day” observations affected by this change.
https://www.inaturalist.org/observations/387323743
I’d appreciate any insight from iNaturalist staff, curators, or others who have dealt with a similar issue.
Seems this is one of the oldest observation fields in iNat, and it has been broken for at least 7 years. @loarie created it.
I’ve moved the above three posts to this first thread to keep the discussion in one place
For those of you who have used this field previously (I have not, so I don’t know the answer), is it purely the name of the field that has changed recently? Or is it also the values/options?
EDIT: ok reading @racronce’s post more carefully it seems like the allowed values have been changed too
I was using actively and i have more than one thousans observation with this field. That change was so wrong. If i edit any of these observations, field text changing to “cave” which is annoying.
Seems people have been using this field to enter free text. Now the field has predefined options, that do not seem to fit the free texts previously entered by users.
What seems to cause the current outcry: The name of the field was changed recently.
So the field needs to be edited in a manner conserving the free texts entered by users, but fixing / reverting the name.
My guess is that even if you can somehow get the field name changed back to “habitat”, it will likely take a long time.
Personally, I wouldn’t want to count on that happening. Based on the example you linked, it looks like the content/value added to the observation is still there, the only problem is that the field name is changed from “Habitat” to “Type of access”. My solution would be to choose an alternative field which does contain the word “habitat” or create a new one of your own, and copy the content of the “Type of access” field into this new/replacement field. It looks like the project has what, 702 observations? Copying this field 702 times would be a bit tedious, but I’ve had worse. And it may be possible to automate this process via the API (I have only ever used the API to read data, not write data.).
That’s my suggestion - take control of the problem and fix it yourself rather than hope that somebody else fixes it for you. Yes, you shouldn’t have to do this, but I’m just being realistic. You can live in hope that some day, someone will fix this for you, or you can roll up your sleeves and tackle the problem head on. It will likely be faster, and far less frustrating to just copy the field 702 times.
In the past, I’ve been critical of folks who created their own versions of various fields that already existed in iNat. I’ve always just used existing fields (in fact, I started using one just a few days ago and have already added it to several thousand observations). I guess I knew it was theoretically possible, but I never imagined that the original creators of these fields would come along and change them. Not sure how to fix something like this. On the one hand, proliferation is undesirable, but the only way to guarantee that someone doesn’t pull the rug out from under you is to create your own.
Bingo!
One undesirable outcome or another based on poor system design. A nice little zugswang to be trapped in.
I sympathize with the original design. Everything else on iNat is tightly controlled, and it’s impossible to account for the requirements of every user, and every taxon. After all, iNat covers every form of life on the entire planet. iNat staff decided to let the observation field be completely uncontrolled, so folks can work around all the other restrictions there are on the platform, and (hopefully) cope with other features not quite suiting their use cases. Indeed, I’ve often used observation fields in this way, and have been thankful that there aren’t a bunch of restrictions preventing me from implementing a workaround for some other shortcoming on the platform.
So it’s not just the users who are faced with a no-win scenario, the iNat staff are as well.
Curators have the ability to edit the name and allowed values for any field, so before anyone starts trying to migrate large amounts of data to a new replacement observation field, why don’t we just restore this one to how it was before the change (i.e., change the name back to “Habitat”, remove the list of allowed values so that it’s an open-ended textbox again, and change the description back to “Provide description of habitat”)? (This will require renaming the recently-created replacement Habitat field first [since two observation fields can’t have identical names], but given that the original field has been in use for almost as long as observation fields have existed and has hundreds of thousands of observations associated with it, that seems more reasonable than simply abandoning the old field and expending a ton of time and effort to copy all its values over to the new one. The new one can then potentially be merged into the original.)
Thankfully, the original setup of the observation field in question isn’t difficult to reconstruct (and from its usage history it also isn’t difficult to figure out who’s probably responsible for changing it [presumably by mistake?]). That won’t necessarily always be the case, though (and creating custom project-specific fields to use instead of the general ones doesn’t prevent other curators from similarly erroneously modifying them), so things like recorded change history, and better safeguards against complete overhauling of in-use observation fields/those tied to projects/etc. (even explanations of the consequences—“this change will affect x number of observations/projects/users/etc.; are you sure you want to continue?” or something), would definitely be helpful to prevent this sort of thing from happening again. (Same goes for taxon links, another part of the site that’s not infrequently edited by curators unaware of the consequences of modifying them, resulting in sweeping changes that unintentionally break or remove links for large numbers of taxa and are often difficult to reverse)
yes, I messaged the person I believe was responsible for this and it was definitely a mistake and they seemed very apologetic about it, though I think a good deal of the fault lies in the platform for making it strangely easy to pull off such a radical change without a trace.
(I’ve gone ahead and restored the original Habitat observation field https://www.inaturalist.org/observation_fields/10)
My guess is that even if you can somehow get the field name changed back to “habitat”, it will likely take a long time.
Personally, I wouldn’t want to count on that happening. Based on the example you linked, it looks like the content/value added to the observation is still there, the only problem is that the field name is changed from “Habitat” to “Type of access”. My solution would be to choose an alternative field which does contain the word “habitat” or create a new one of your own, and copy the content of the “Type of access” field into this new/replacement field. It looks like the project has what, 702 observations? Copying this field 702 times would be a bit tedious, but I’ve had worse. And it may be possible to automate this process via the API (I have only ever used the API to read data, not write data.).
That’s my suggestion - take control of the problem and fix it yourself rather than hope that somebody else fixes it for you. Yes, you shouldn’t have to do this, but I’m just being realistic. You can live in hope that some day, someone will fix this for you, or you can roll up your sleeves and tackle the problem head on. It will likely be faster, and far less frustrating to just copy the field 702 times.
In the past, I’ve been critical of folks who created their own versions of various fields that already existed in iNat. I’ve always just used existing fields (in fact, I started using one just a few days ago and have already added it to several thousand observations). I guess I knew it was theoretically possible, but I never imagined that the original creators of these fields would come along and change them. Not sure how to fix something like this. On the one hand, proliferation is undesirable, but the only way to guarantee that someone doesn’t pull the rug out from under you is to create your own.
This is such the entirely wrong way to go about this. We have a high-level data integrity failure on the site that requires administrative action to both remedy the problem and prevent it from recurring. Shifting the onus to the individual user to come up with a bubble gum and popsicle stick solution, while telling us not to expect anything better, is a baffling point of view to take in this thread.