Hi,
I am trying to find how an identifier discovered an observation before adding his/her ID. There are many ways, as far as I know, that can lead an identifiers to an observation, such as:
the observation was under a project which the identifier was following
the observation was made an observer whom the identifier was following
the observation was a taxon which the identifier was following
a followee of identifier has previously added an ID to the observation
identifier used a custom search
identifier was @ mentioned by someone in the comments section
a notification to identifier for any other subscriptions
other referrers…
It would be useful to have the referrer information in unauthenticated /identifications and /observations GET endpoints.
FWIW, our API is largely something we use to make iNat work, so data should drive functionality. If there’s a feature we think is worth building that relies on how an identifier arrived at an observation, then we might start recording that information and include it in the API, but we’re not going to include it in the API just because it seems interesting.
Also, I’m not really sure why this information would be of general interest. Those of us on staff might be interested in this kind of data to understand what tools identifiers are using so we can focus our resources differently (e.g. if identifiers use Explore more than Identify, maybe we need to ditch Identify), but I don’t understand how that information helps people using iNat.
I always thought that information about users, including identifiers, would be limited to matters that are clearly intended to be public on the user interface. I don’t really like the idea of this request, from the standpoint of some users getting information about identifiers/other users that isn’t clearly intended to be public.
If you knew that one observation was identified by someone using Identify while another was identified by someone using Explore, how would that help you make a more “attention grabbing” observation in the future?
I can’t see how that info is useful to the observer.
As an identifier I can’t see why that info would be relevant to the observer.
If the question had been - how did the identifier get to the ID …
(this query is coming from the parents of a child, according to the iNat profile)
A stretch, it’s true, because a lot of the bullet points in the original post are out of the observer’s control, but surely a person could think of ways. For example, if many identifiers find observations through projects, the observer could make sure all their observations are added to projects. I’m speculating here, and certainly we won’t know googleuser6’s reasoning unless they share it. Maybe they just like data.
You’re going to hate the next redesign we’re working on:
As someone living in the Giant Western American Smoke Cloud, I am also going to hate this redesign.
As your question points out there are many ways to find an observation. One of my favorite things to do is to add annotate and add observations to projects I’ve joined. I’m especially fond of worldwide projects. I really enjoyed annotating and adding slug caterpillars in India to the Insect Larvae project. What I do most however is search for parasitoids to add to my project Passengers looking at a variety of taxa.
Every now and then I take a break from bugs and see if I can help Pintail in South Korea with his plants. (Some of the same ones are grown as ornamentals where I live in South Carolina.)
Occasionally on the phone app I Explore using the map and I identify whatever I can between Hendersonville NC and my home.
Sometimes someone identifies an observation of mine and I see if I recognize anything of theirs.
In short it varies how I find other’s observations.
I was told by a friend that research grade observations are not always accurate, this being a citizen science. And, that iNat’s decision to remove the “Agree” button was a step toward improving the quality of IDs.
Understandably there could be a multitude of reasons for a mis-ID. My guess is that part of the problem could be a sort of authority bias or confirmation bias. To understand the bias in ID better, I need to start with observations that have disagreements on the ID, at any taxon rank. How an identifier got to the observation could provide critical information on typical paths of bias.
I do not expect this “referrer” to be shown in app, but just making it available through the API would be fine.
That’s correct. I am trying to explain my 5yo that ID can sometimes be wrong. I just don’t have an answer to why community ID can be wrong sometimes.
Thanks for expanding on the reasons behind this interest @googleuser6. I think all that supports the idea that the iNat dev team might want to look at identifiers’ paths through the UI to answer questions such as these:
How do people to tend find observations that they provide IDs for?
How do people navigate the interface while providing IDs?
Are particular access routes or search patterns associated with IDs that have better/worse support?
Of course, there’s a lot of other things that feed into the ID process outside of these user experience factors.
But I don’t know that any of this info is valuable to people outside of iNat staff, and it seems there are some privacy concerns with exposing this info so that it can be queried through the API. I’m guessing that you personally were curious about this and discovered that info isn’t present in the API. That makes sense, but maybe isn’t enough reason to justify collecting and exposing it.
why is the ID wrong? I use my notifications to follow conversations, IDs can wax and wane like the moon or the tide.
Someone works on that bit of taxonomy, shuffles all the cards …
An expert on Genus species subspecies sorts thru years of records on iNat.
Some of these identifications are guesses. But some guesses are more educated than others. Learning is going from what we know to what we think we might know. Only to realize we know less than we thought, but more than we knew the day before.
