Various small bug fixes and improvements, like making sure focus goes to the text field when a curator hides content, or filtering by state of matter life
Haven’t thought that far ahead yet. The main issue here was that Seek defaulted to a specific location and date if the observation didn’t have one or the other, and this was the cleanest way to prevent that from happening.
I suspect we won’t totally block uploads for iNat in these cases. We already provide warnings in the web uploader if this info is missing, as well as in the new app:
It’s some good progress towards preventing junk uploads to the site.
Another very good step in that direction would be stopping the creation of observations without any media attached to them. There are huge numbers of “observations” which have neither photograph nor sound recording attached to them. At the very least the creation of them should be stopped if it hasn’t already been.
If new creations have indeed already been stopped then going through and deleting all of the old junk “observations” of that type which exist would be a good idea too. They clog up the casual section of the site and may even reduce database performance since over all species there are likely hundreds of thousands of the things.
First off, there’s no need to use derogatory language, i.e.,
when referring to how other users engage with iNat.
There are legitimate uses for media less observations. I have a few myself for cases where I have observed something, but haven’t gotten a photo. I want to remember the location and details, but don’t have evidence. This is no different than writing down field data in a notebook which is standard practice for researchers worldwide still (and was the predominant way of recording data until the widespread availability of digital cameras 20ish years ago). iNat staff have made clear that they approve of this type of use and have no intention of forbidding it.
These observations are not in the ID queue by default, and are trivially easy to exclude from Explore/Identify/searches by selecting for observations that have specific media, so they aren’t an issue for the platform.
We expect you to submit information that you believe is an accurate assessment of the evidence provided …
Now that continues on to refer specifically to deliberately false IDs and DQAs. However applying that phraseology only very slightly more widely and that was exactly what I was doing with what I said that you objected to. An “accurate assessment of the evidence provided”. No evidence is provided for the entries I referred to. They are mere unsupported assertion.
So what am I supposed to call such unsupported assertions? They are not amenable to identification. They will never be amenable to identification. Even with unfortunately utterly blurry pictures or low quality sound recordings there is the possibility of attempting ID. It might be such a small possibility that functionally it does not actually exist in reality. Nevertheless it is theoretically there. With the unsupported assertions it is not even theoretically there.
Do tell what adjective should then be used to describe such assertions on a platform such as iNaturalist?
Nothing. You’re not supposed to do anything with such observations. They’re not verifiable. They exist for the purposes of the observer. They’re of no concern to you.
The average eBird observation involves the same level of evidence and they are sent to GBIF in that state. eBird does require comments for unusual submissions and those are vetted by experienced reviewers, but technically anyone on iNat can add correction IDs or clarification requests to media-less obs as well.
just an headsup, if you use proper URL filter, such query is already efficient in finding things ones care of and so what matters atleast to me is realtime performance in those cases with filter like &photos=true or &sounds=true. Any perceived clog/reduce-db-performance is almost nil in such desired filter; even if there are hundreds of thousands of such things on entire site one proper “specific search” URL query will rarely effect db query performance for that user interactions.
if you meant they clog the storage (mute as they are medialess in first place so 100-1000x low storage) and there is background processing to organise these by site, it comes with any data storage mechanisms, "suppose I only care of xyz datapoint, so everything else that inat serves on site by default via its API full fields results beyond my usecase looks performance reduction to me ", so just as there is need for other data fields for others, there can just as be need for these medialess observations for lots of others usecases.
and as others said of ebird and pre-inat, even if modern science is reliant on explicit evidence by media, go back to 300 year old literature, and all I see mostly are three line sentences for n.sp. descriptions and pray that there are no later lookalikes and hope someone offered differential diagnosis atleast for that future similar species yes those descriptions can be revalidated today from taxonomists and new evidence but the point remains they were anchored as medialess text too in first place or as a note in new survey checklists akin to medialess observation at location and date.
", so just as there is need for other data fields for others, there can just as be need for these medialess observations for lots of others usecases.
yes those descriptions can be revalidated today from taxonomists and new evidence but the point remains they were anchored as medialess text too in first place or as a note in new survey checklists akin to medialess observation at location and date.