as far as i understand it, an iRecord verifier will get an iRecord record – which will be recorded at species level – and they confirm or deny it. i don’t see how that kind of workflow would be any more work than if they looked for species-level records in iNaturalist and confirmed or denied those. in order for a record to get to species level in iNaturalist, it will need to have been identified at least once by the community. in fact, if iRecord pulls in only RG records from iNat, they would get iNat data potentially faster if iRecord verifiers did their verification of iNat records in iNat. especially for hard-to-ID taxa with few potential identifiers, it doesn’t make a lot of sense for 2 identifications to be made on the iNat side (the minimum for RG) and then essentially a 3rd verification to have be be made on the iRecord side, if instead 2 identifications could be made on the iNat side to reach RG and then (assuming one of those IDs was made by a linked iRecord verifier), the identification could be translated with an automatic verification over of the iRecord side.
it seems to me that the whole point of the extra verification step is for particularly hard-to-identify taxa – otherwise, the community identifications from iNaturalist should usually be enough to produce a good ID. the only other process option would be to to pull in records from iNat prior to RG once it had reached species level, but then that’s potentially a different process to transfer the data than usually happens when iNat sends data to aggregators, and it’s not clear that that would be a better overall workflow.
Here is one example. At time of writing, according to the ID by UK scheme leader @macadac, this has two incorrect IDs to overcome. It is stuck at family level. Even if I step in to add blind-agreement weight to @macadac’s ID, it will still be stuck at family level. He (or I) could tag in the original identifiers and/or other identifiers to ask them to fix it - but then we would still have to keep tabs on it to know if it was resolved (and quite possibly chase up down the line). In iRecord it would simply be redetermined to the correct species ID and the verifier would be able to move on. I totally get that this is a more time-consuming process and a less-inviting system to use from the verifier’s POV.
That would be fine if they automatically passed through to NBN, but then why use iRecord as a gobetween whatsoever? That would just double the workload. I think in the workflow you are talking about, iRecord serves no purpose. Automatic verification within iRecord from recognised iNaturalist identifiers would just be the same as bypassing iRecord entirely (?)
The verifiers certainly don’t appear to think so from the comments I see off-site.
Watching UK Diptera verifiers who are active within iNaturalist I would also say this is not the case. But this is well debated, and lacking in hard evidence one way or another still as far as I can see, beyond saying that accuracy varies wildly by geography and taxa. For me, I can’t speak outside of my geography/taxa, but I wouldn’t trust iNat UK Diptera data personally without checking the set through one by one. It’s just too easy for mistakes to fall through the cracks.
I think perception of a verifiers job as only being to double-check an ID is misplaced though as well. They are also checking date/location details appear correct …and rightly or wrongly there are a broad range of complaints about these aspects of iNaturalist data too, as well as complaints about lack of annotation.
It’s not a matter of how the API is designed. It’s a matter of policy: we want activity on iNat to be associated with individual people and generally don’t like “group” or collective accounts. While the questagame situation is a good example of one problem with group accounts (it’s not reasonable to compare the work of a large group of people with individuals, as we do on several parts of the site), the main problem is that we don’t think groups are as responsive or accountable as individuals. We think an individual person is way more invested in taking care of a record that they put the work into creating. This is also why we don’t like people just uploading massive archives of data that were collected by other people.
Yes, makes sense as a broader policy. On the iRecord side, importing massive archives of iNat data without having users the verifiers can dialogue with directly is also causing issues in the same way, so I certainly get this POV. It’s just a shame in this instance, as it feels like a such a missed opportunity for UK iNat users to have the UK experts look at their records but have no idea if they are confirming the IDs or not. I just wish there was a workaround as it would massively change the landscape for iNaturalistUK. But perhaps iRecord will just submit to using the API in the way iNat allows.
Might there be any chance of a link to the datapoint on NBN / iRecord in the same way GBIF links up? That would be better than nothing I think.
in this example, the verifier still just moves on. the record may not push over into iRecord right away (until research grade is reached in iNat), but when it does eventually reach iRecord, if there is functionality to automatically verify the record based on the linked observer’s ID, then the verifier won’t have to look at it again in iRecord. it will automatically get converted to whatever the verifier previously identified it as in iNat.
what i’m suggesting isn’t shortening the path to research grade (and then interface). (that path to research grade is just what it is, based on iNat rules. that’s not going to change.) what i’m suggesting would simply provide a way to eliminate duplicate verifier work on both ends while making sure the identification ends up on both sides.
because:
this would allow iRecord verifiers to still participate in the process even if they refused to use iNaturalist.
if a record made it through iNat somehow with RG on taxon A but a linked verifier identified it in iNat as taxon B (maverick), then with the automatic verification passing through iRecord, it should pass it through on taxon B without a verifier having to do anything additional in iRecord.
if that’s other stuff that they’re doing as part of their process, then the interface process could potentially also check to see if the linked verifier had marked certain DQA flags, and then those could be automatically translated during upload into iRecord.
Not sure. If there’s an automatable way to query iRecord observations that come from iNaturalist that returns the iNaturalist observation ID or URL, then we could set up a system to poll that regularly and update our own records of which observations are in iRecord or not. Alternatively, if there’s some API for generating an export of just the iRecord records that came from iNat, we could use that. After 15 mins perusing iRecord I didn’t see an obvious way to do either, but if someone with better knowledge of iRecord can point me toward some docs maybe we can make this happen.
But ok, thankyou for looking! Much appreciated. I’ll pass this back on to the Facebook thread and see if John van Breda gets back to me with further info on their side.