What is a Pre-Maverick Archive
Observations that used to be here:
https://www.inaturalist.org/projects/pre-maverick
but now arenāt, so they are here:
https://www.inaturalist.org/projects/pre-maverick-archive
It has to do with observations with conflicting IDs.
4 Likes
Original suggestion to do it, at the bottom of this journal post:
https://www.inaturalist.org/projects/pre-maverick/journal/75148-algorithm-for-finding-the-pre-maverick-observations
4 Likes
@tiwane probably been asked a thousand times about features; but can a āmaverickā filter be added to the filter features? Basically a toggle to show everything in the group that is āMaverickā. Itās useful to work on them, but I canāt use the SQL-type code iNat works with well enough to sift through all the various areas. If I could set Cicadoidea and California, then toggle Maverick, or the US in general and any other combination it would be fantastic!
Asking here; if itās possible Iāll request the feature in the proper place thread
2 Likes
Maverick = RG and CID is happy
Pre-Maverick = That One is holding back CID and RG. You can use Pre-Maverick to filter by project
Californian cicadas 98 waiting
Then keep tweaking to suit
1 Like
what would a useful version of this even be? by the time an identification is labeled as a maverick, do you really still want to see the observation? (probably only in cases where the maverick ID is the latest ID on the observation, right?)
iNat has a some filters that may be useful for finding disagreements, but there are many possible configurations of disagreements, and thereās not really any filter currently that will find all these configurations that might be of interest to an identifier.
hereās an example of way to find observations that likely have a single bad id countered by a single other id: https://www.inaturalist.org/observations?identifications=most_disagree&lrank=genus&place_id=any&ident_taxon_id=50190
but thereās not really a filter that will reliably find cases where two IDs disagree with another single ID.
so if youāre looking for specific cases for iNat to automate the search for, i think you need to very explicitly define what the characteristics of these cases are, and put these in a feature request.
here are some examples of the kinds of situations that folks might be interested in finding:
- observations with multiple leading IDs
- observations where a maverick ID is the latest ID
- observations that include an ancestor disagreement
There was not.
Which is why JP wrote the code and built the project. Ideally it would be a function that iNat offered, without him having to run the code first.
Well over half a million obs, but only added 12K from the third run. We make progress!
5 Likes
I just went through the Pre-Mavericks in my region, and I not only learned a lot and got a lot of IDs in, but it was very satisfying and enjoyable.
Itās not all obscure and difficult. It is a combination of obvious ids and less obvious ones. The easy ids were computer vision failures or initial observation guesses that were wrong, and there just hadnāt been enough knowledgeable identifiers looking at it to overcome the initial bad guess (and the original observer was long gone). These were satisfying to clean up and get to research grade.
The less obvious ones were great learning opportunities. Obscure species not often observed and with few identifiers that knew them. This is where the greatest learning came from - in my case, these were plants I could add to my knowledge base.
Perhaps less interesting were ambiguous photos that just werenāt definitive enough to rule out one or the other species.
Donāt let the power go to your head. Itās like being a judge presiding over disputing parties. You can be the deciding vote, so be careful!
10 Likes
while it may be true that this project may help you make progress, my own opinion is that the project captures only one of the cases that folks area really interested in, it doesnāt capture these completely (since some folks donāt allow others to add their observations to projects), and there are ways to make progress without the confusion that the project occasionally causes (as evidenced by the existence of this thread).
my opinion is that the best solution is still going to be to define the complete set of cases that are hard to find with current filters. from there, itāll be easier to figure out exactly how to get the system to find all (or more of) these cases.
3 Likes
The confusion is there already.
It would be wonderful if iNat built a tool with options and filters.
Meanwhile we do what we can with what we have. 2 against 1 has the possibility of an easy resolution.
Multiple leading IDs is probably a thoughtful scientific discussion, where taxon specialists have already brought their varied opinions.
4 Likes
It is their free choice not to participate to (possibly useful) projects (being aware, or not, of the consequences).
We will not renounce to move on, using projects as needed, just because some folks opted out (of traditional projects). This is (possibly) an issue for them, but not for us (identifiers), as there is still enough work left to do.
The algorithm used is described in the project journal post. It can be improved, but we got already many observations. iNat could provide an equivalent feature and make it even better. Ask for the feature and we will vote for it and participate. Meanwhile, we already have this solution and we are still improving it (with this new Archive project).
I develop software and then I see who uses it and if it was worth the effort. I focus on what helps us, not on the observations we miss because of limitations.
For a similar reason (for helping identifiers), I made 2 projects for collecting observations from people who have "opted-out" (of the "community taxon"). In March 2023, I was asked to delete these projects and at the same time iNat staff told me that they were investigating how hard it would be to implement on a technical level.
This exemplifies that a feature we develop with software and traditional projects, when successful, may motivate iNat to provide the feature directly.
11 Likes
Maybe everyone here already knows about this? you can add category=maverick to identification URLs. For example, I check my idās with this URL: https://www.inaturalist.org/identifications?user_id=conorflynn&category=maverick
1 Like
You can. But Maverick is too little too late.
That is already satisfying the CID algorithm and at RG. Your Maverick disagreement makes no difference either way. Another identifier has put in the time and effort to counter your Maverick ID.
2 Likes
Oh, I seeā¦thatās why this is about āpre-maverickā observations. Thank you, I will use that project to filter taxa in need of ID.
4 Likes
2:1 is just just a subset of multiple leading IDs, right? why is 1:1 or 3:2 more probably a thoughtful discussion ā or any less easily resolved ā than 2:1? you could even think of 1:1 as just āpre-pre-maverickā, right? as an identifier, why wouldnāt you want to go after those, too?
my point is not necessarily to poo poo the existing āpre-maverickā effort or to say that āmultiple leading IDsā is necessarily superior. my point is that going through the process of defining a feature request to implement some sort of standard filters to help identifiers find observations of interest would help clarify the most efficient path to help the most people. in other words, there are many ways to take a step forward, but is the current āpre-maverickā concept a step that ultimately leads down the best path?
3 Likes
I want to make efficient use of my time and ID skills. This works for me - I can tackle what I can ID. Perfect is not on my list. Good enough is. I want to nudge the problems along to where taxon specialists can focus on doing āperfectā.
2 : 1 needs 1 more (unless it tips the other way to 5 : 2)
1 : 1 is wide open and ticks along
3 : 2 needs 2 more, or 5 the other way.
Just the one more is the low hanging fruit.
4 Likes
I believe I a actually meant the āpre-Maverickā, but it looks like there is a project. I have looked at it, but the code required to put together for an observation is too confusing for me @dianastuder
Thatās why I though a toggle at the end of pre-existing query might be nice, but it seems like that alters the base code a lot?
If you have a bookmarked URL - use the project filter (JP has done the hard work and we can simply use it)
Pre-Maverick
Then the usual tweaks for taxon and location if needed.
Here you go
6 Okanagana
My random click took me to an obs you are already discussing.
1 Like
Scrolling down the start of the earlier comments it seems everyone but me knows what a maverick is in this context. Definition please, anyone?
Here are definitions of the types of identifications https://www.inaturalist.org/pages/help#identification:
- Leading: Taxon descends from the community taxon. This identification could be leading toward the right answer.
- Improving: First suggestion of this taxon that the community subsequently agreed with. This identification helped refine the community taxon.
- Supporting: Taxon is the same as the community taxon. This identification supports the community ID.
- Maverick: Taxon is not a descendant or ancestor of the community taxon. The community does not agree with this identification.
2 Likes