81. Gegevens die getoond worden in de verkenner
While iNaturalist has many uses, one of the core audiences of the site is the natural history and biogeography communities who are interested in the distribution of established populations.
This is why, by default on the iNaturalist Explore page, we filter by observations that have all their core attributes (media, location and date not missing or flagged as inaccurate) and also are wild (e.g. not cultivated plants or pets).
The graph below shows the flow of observations posted to iNaturalist into each of the 3 bins: Casual, Needs ID, and Research. This subset of observations that are missing attributes or are captive/cultivated end up in the Casual bin. Everything else (Needs ID + Research) ends up in this subset that we filter on the Explore page by default. Observations with a community taxon at the species level are Research, otherwise they are Needs ID.
We can thus achieve our goal of filtering observations that are not missing attributes and are wild on the iNaturalist Explore page by default by filtering for NeedsID+Research (but not Casual) observations.
Not Established Obs such as Escaped and Released Pets
For the same reason we don’t want to show captive/cultivated observations by default on Explore, we also don’t want to show observations of released or escaped pets or individuals that otherwise don’t represent established populations. We feel that narrowing one’s focus on established observations is useful to:
- Highlight mis-ID’d taxa
- Highlight discoveries of new established populations
- Browse iNaturalist like one would browse a field guide (which typically include established native and introduced species, but not escaped pets)
And while the number of escaped observations is tiny, often a significant number of species in the species tab are driven by these observations. Non-established observations include things like escaped and released pets, hitchhikers (e.g. the frog in the Home Depot plant). Obviously, there are gray areas with regards to vagrants and species established in greenhouses etc., that we’d need to come up with norms for. We’d also need to come up with norms for plants which are perhaps less clearcut than animals? And sometimes establishment is difficult to know for sure (e.g. long-lived turtles in ponds). You can see examples of observations currently being tracked as non-established with this observation field.
Related to this, there is ongoing ambiguity within the iNaturalist community about the meaning of the ‘wild?’ Data Quality flag. Some people interpret it as captive/cultivated at the time of observation (e.g. ‘is this snake in a terrarium?’). Others interpret it to mean ‘member of an established population’ (e.g. ‘is this snake on the lawn an obvious escape from my neighbor’s terrarium?’). We’d like to bring more clarity to how the ‘wild?’ flag should be used.
We’ve discussed several options for how best to track non-established observations from the existing ‘wild?’ flag, the existing ‘Escapee/Non-Established’ observation field, to a new Annotation. Our preference would be to create a new data quality flag similar to but separate from ‘wild?’ - e.g. ‘established?’
This would avoid concerns about not being able to easily filter escapees separate from captive/cultivated observations (if we were to use the broader interpretation of the existing ‘wild?’ field) as well as concerns about involving observation field or annotations in default Explore searches (if we were to use the ‘Escapee/Non-Established’ observation field or a new annotation).
Other advantages of this approach is that it would be very quick to implement. We’d simply:
- Add a new ‘established?’ data quality flag
- Clarify that ‘wild?’ refers to captive/cultivated does not include released/escaped pets
We could quickly make the new ‘established’ data quality flag parameter available in a url search to filter for unestablished observations, it may take us a bit longer to add a ‘established’ button to the Explore page filters.
Disadvantages are that we suspect some will take issue with these escapee observations being casual for the same reasons that some have taken issue with captive/cultivated observations being casual. The main argument is that captive/cultivated observations can still often be identified and are applicable to certain research projects so the name ‘casual’ isn’t appropriate.
More ambitious alternative
Another more ambitious/disruptive alternative would be to bundle this work with additional work to remove ‘wild? No’ from casual as in the graph below.
More ambitious alternative
Another more ambitious/disruptive alternative would be to bundle this work with additional work to remove ‘wild? No’ from casual as in the graph below.
This would mean that captive/cultivated observations would be in Needs ID and Research. But we would add an additional set of search filters to Explore that default to excluding Casual, Captive/Cultivated, and Non-established observations by default.
The advantages would be that captive observations can become ‘research grade’ which might encourage people to identify them. You also would able to search for captive observations with out a species level Community Taxon (by searching for what will become Needs ID, captive/cultivated observations) which you can’t do now.
The disadvantages here are that this won’t do much to extend what people can already search for, it mainly just alter the philosophy of what casual should or should not include which might displease as many people as are pleased by the change. It also adds a new dimension complexity to accommodate a tiny fraction of arguably less relevant captive observations. Lastly, it will be a much more ambitious (longer time frame) project to implement requiring:
- Add a new ‘established?’ flag (as above - but not part of the Research Grade calculation)
- Update Research grade (RG) calculation to also remove ‘wild?’ from the calculation
- coordinate RG update with changes to/impacts on many parts of the site including:
- check lists
- atlases
- the computer vision model data export script
- every project that has an existing RG requirement
- every partner consuming our data that may be assuming RG means what it currently means.
- relevant documentation that refers to the current definition or RG
- On the observation page make clear that ‘wild?’ And ‘established?’ aren’t part of the RG calculation
- Add new search filters for Captive, Non-Established, and Established for Explore and Identify.
- Set the default search filters on explore to be Needs ID + Research (not Casual) and Established (not Captive or Non-established)
We’re curious what you think about these options given these tradeoffs.
https://github.com/TlaskalV/iNaturalist_app
https://labenvmicro.shinyapps.io/iNaturalist_app/
Comentarios
DEze test is veel beter
Hoe was die andere test ??
Slechter....
Agregar un comentario