Add URL Parameter to only show observations with disagreements

Platform: Website, specifically identify mode

Description of need: A URL like ident_disagreement=true which only shows observations with a disagreement

Feature request details: I generally add broad IDs and clear unknowns to lower the observation to at least order or family level. I have finished all unknowns and all animals down to at least order level in my area and I was looking for new observations to Id. I started checking older observations and saw that most were identified by someone but wasn’t agreed which caused them to be left at a very high-level id and lost in time. Being able to only get observations with a disagreement would help clear those faster.

Uses for this feature would be:

  • When observer uploads a commonly misidentified species and doesn’t change their id when someone identifies the correct id. Which causes the observation to be lost in time for years.
  • There are people who go through research grade observations to find mistakes and when they do find one, they make a disagreeing id. Using the URL parameters to get observations with a disagreement and from a specific identifier would make it easier to clear those.
  • When you know some people who commonly make mistakes.
  • When certain people make joke ids, you can use URL parameters to find those people and correct their id.

I personally wouldn’t have a use when people disagree and add a kingdom-level id, but having the option would surely benefit some people. The main identify mode doesn’t have that much way to narrow down what you specifically are looking for and these URL parameters are really useful. I don’t see a drawback for this feature except for maybe the difficulty of adding the feature. I’m not really that familiar with the coding aspect. I’d like to know what you think about a feature like this. Would you have a use for this?

When I see someone has made joke IDs, I just go to their profile and from there to their identifications. Would this not work for you? Most joke IDers that I’ve encountered are not prolific IDers, so it’s not a lot to go through, but if that is not your experience I can see where this would be useful.

2 Likes

Yeah, for situations like that going to their profile would be better. It doesn’t happen that often but in instances where a lot of new users appear and star misusing the platform this could maybe be useful. My main point wasn’t that, to be honest.

1 Like

there are multiple types of disagreements. so instead of just =true/false/any, i think if this were implemented, it should allow differentiation between normal disagreements and (potentially different types of) ancestor disagreements, too.

i think in a way, this is very similar to https://forum.inaturalist.org/t/url-parameter-to-exclude-taxa-by-identification/30266 and other new features requested in the past, though each approach has their pros and cons and potential set of use cases. i think these kinds of requests just go to show how many different identification workflows there are out there.

5 Likes

That’s a great point but I feel like it would complicate the process. As you said all these requests have pros and cons. Specifying which kind of disagreement to show with only 3 or 4 lines of text would be hard. Maybe a more basic version of this can be considered. For example, if the disagreement is on the same tree of life or not.

1 Like

Does this help at all?
https://www.inaturalist.org/identifications?&category=maverick

2 Likes

That’s a great tool but not exactly what I’m looking for. The maverick category only appears when that ID is countered by other IDs. I want to filter observations where there is a disagreement and the community ID is stuck at a very high level

2 Likes

If @pisum can build an URL for you … if he can’t, you will have to wait for iNat staff, maybe, one day … Meanwhile we have to workaround with what we have.

Meanwhile @jeanpaulboerekamps has built the
https://www.inaturalist.org/projects/pre-maverick

You and I were looking at Pre-Mavericks almost a year ago.

3 Likes

I discovered that project a while ago and it’s an absolute life-saver. Thanks for being a part of it.

1 Like

using existing parameters and tools, i think there are only ways to get observations that are likely to have disagreements.

for example, suppose we look at the screenshot in the original post example, and we suppose that the user here wants to follow m_gokmen’s IDs because m_gokmen is a trusted identifier who typically identifies to a low level where possible. if that’s the case, then you could look for observations at a high level (like class) where m_gokmen has made an identification. the resulting set of observations should include a lot of observations that have disagreements: https://www.inaturalist.org/observations/identify?lrank=class&ident_user_id=m_gokmen.

you can also use a page that i made which will allow you quickly see where there are IDs at taxa that are either descendants to the community taxon or are not related to the community taxon. these should be indicators that there’s a disagreement, but this page may not be as streamlined for identifying as the Identifications page is: https://jumear.github.io/stirfry/iNatAPIv1_observations?lrank=class&ident_user_id=m_gokmen&per_page=200&options=idextra&idextra_user_id=m_gokmen&reviewed=false&viewer_id=doruk912

or suppose that you know plants in the aster family. then you could look for cases where there has been an identification within that family but where the observation is currently at a higher level (like class). this set of observations should mostly include a disagreement somewhere: https://www.inaturalist.org/observations/identify?lrank=class&ident_taxon_id=47604. and here’s the view from the page that i made: https://jumear.github.io/stirfry/iNatAPIv1_observations?lrank=class&ident_taxon_id=47604&per_page=200&options=idextra&reviewed=false&viewer_id=doruk912

3 Likes

Thank you - have added daisies in the Western Cape to my list.
With your URL I can keep tweaking…

2 Likes

We discussed this request and won’t be moving forward with it for the foreseeable future because it would unfortunately require reindexing observations, among other complications. I’m going to close the issue.

For now I’d recommend using @jeanphilippeb’s project, or using the some of the methods @pisum suggested.

5 Likes