I’m making up data labels for some voucher specimens I’m collecting. If I include a line for iNaturalist observation number then include the number string from the end of the URL… will that number ever change? the idea is that in the future if I or someone else wants to add microscope photos of that specimen we can or if it gets identified as something else we can go back into the original observation and change it.
Once assigned, there is no process that changes an observation number. And there is no merge tool which might cause it to get merged into a different record.
- there is no guarantee the observer will not delete the record
- I don’t speak for or am employed by the site, so while I can not imagine them doing it, is it theoretically possible they change the format of identifiers in future.
Thanks, I will be the observer in most cases and its good to know that in theory I will be able to link the physical specimen with the digital record hopefully indefinitely.
You can see an example of another research team doing something similar here: https://www.researchgate.net/publication/328795572_iNaturalist_as_a_tool_to_expand_the_research_value_of_museum_specimens
i don’t speak for the staff either, but i can imagine some reasons for adopting a new ID system in the future, though i would think that if they adopted a new ID system in the future, they would do it in a way that is as backward compatible as possible, where most of the time, you would be able to get back to observations originally created in the current ID system.
i think if you needed absolute certainty that IDs would not change, you might consider an alternative, such as described here: https://forum.inaturalist.org/t/incremental-counter-in-a-custom-field/11892.
I’ve used iNat observation numbers in scientific pubs (though minor ones) as well. They seem to be quite stable, and I haven’t heard of any plans to alter them, so they seem the best option for the time being.
One note RE: using iNat as an add-on to natural history collections (as in the article @jwidness posted). When that was first proposed, I believe there were some concerns that iNat observations that were also added as an herbarium record could be systematically double-counted on GBIF if the herbarium contributes specimen/record data to GBIF. I’m not sure if that issue was ever solved or not in the specific case of the Carnegie (in article), but something to think about if that is a use you are considering.
I can think of reasons to do it, heck were I designing it today I would use a different approach for an observationID, I just don’t envision it being done.
Observation fields could be risky too given their open nature. If I were so inclined, or even did it by accident, I could delete any observation field (not the value assigned but the whole concept of the field) I wished.
curators might be able to delete, but i don’t think regular folks can. that said, there are multiple ideas presented in that other thread, and observation field is not necessarily the best. you can also use tags, or you could simply add an id in your observation description. i don’t think careless or malicious curators can mess with tags and descriptions, and tags and descriptions are searchable, too.
The observation IDs and the associated URLs are part of iNaturalist’s REST API:
So they must be quite stable.
Would that not mean you would expect the format of the ObservationID in terms of datatype etc is stable, not that the number assigned to a specific observation is ?
Why would anyone want to meddle with Observation numbers, how often is such a number used in a link on an other obs. for reference!
I’m not suggesting anyone would either want to or should do it, merely that the only people who can absolutely promise it would never happen are the site developers.
You can also use other metadata to get back to the observation. If I revise an ID of my photos, I simply search for the date and/or species to find it on iNat and revise it here too. Or vise-versa - to get from iNat to my photos.
Observations, and many data elements also have an associated field called uuid which is visible through examining the JSON of the record, and perhaps via API calls (not sure about that).
It look to be a GUID or similar and is likely permanent as well being related to the database row itself.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.