iRecord verification feedback into iNaturalist

A further response from John van Breda on the Facebook thread:

iRecord already has a functioning synchronisation system which is able to provide verification comments back to other systems. However the other systems “pull” the verification comments from iRecord using a single set of authentication details that covers all the records they pull. Likewise iRecord “pulls” the records from iNaturalist as it’s more efficient to do this in-bulk, than to authenticate as multiple different people and push each recorder or verifier’s data separately. Because iNaturalist relies on all interactions with the API being from an authenticated person, and because the onus for developing the bridge has been on the iRecord end up to this point, we cannot use the existing code. We’ll have to develop some unique code, plus my expectation is that this can’t be as efficient as a single authentication pull based approach. Also, we are aiming to simplify things for verifiers, and with the plethora of other potential record sources it’s not ideal to expect the verifier to maintain multiple system logins within their iRecord profile - it’s not just iNaturalist that these issues apply to.

I recently had a record on iNaturalist get the comment “Record verified on iRecord. Thanks John.” So has this comment appeared automatically because he verified the version that had been transferred to iRecord?

https://www.inaturalist.org/observations/66048988

3 Likes

Ok interesting.
No, there is no automatic commenting possible at the moment as I understand - just there is a link to the original iNat record from within iRecord if the verifiers wish to switch platforms to post something. Nice to see at least one has.

I have also dug into the iRecord records to try and find my own records there which are now being verified. Frustratingly, its impossible to search by one’s username, but for example filtering “all records” just to taxa/locations I observe, I can see some of that which has been checked over belonging to me.

Then I wonder why he is doing it that way. I’ve seen someone else’s woodlouse observation where he has told them he has verified it on iRecord. If he has to log in to iNaturalist to type the message, it would be quicker for him to just click on our agree button.

1 Like

I imagine so that the user doesn’t then choose to log it directly on iRecord down the line and create a duplicate (?) I think there is quite a bit of confusion from verifiers on how to interact with iNaturalist though - many could probably do with some onboarding tips.

“iNaturalist would not allow iRecord to connect to the API via a single “system” authentication”

Does anyone know why the API is designed like this? I wondered if it was connected to that gaming app which used iNaturalist and caused problems in the past ( be good to know if there is a specific reason that I can use to help explain this limitation to the UK folks discussing it on Facebook )
@pisum @zygy

2 Likes

I don’t know the specifics; you’d have to ask one of the developers like @kueda. I do know that the experience with the Questagame app was less than ideal. My understanding, which may be incorrect, was that they were using a single system login to post observations and then pulling verifications from iNat, which is sort of the inverse of what you’re proposing: pulling observations from iNat and using a single system login to push verifications back. In either case, I think the problem is the same: as an iNat user, you can’t effectively communicate with a “system”. It’s often necessary to convey information, questions, or requests to the person who posts an observation or identification. If that “person” is actually an entire website or app, the communication doesn’t work. This robust communication model is one of the reasons why I think iNat has been so successful, so I can’t blame the developers for wanting to stick with that paradigm. At the same time, it sure would be nice if there was some way we could benefit from all those verifications on iRecord.

3 Likes

Ah yes, Questagame… that was it’s name.
Ok yes. Difficult one. I think I’m beginning to see both sides.

How about a link to the external datapoint as we see with GBIF?
I guess that’s quite different as it’s mainly implemented from the iNat side…?

1 Like

i don’t really understand how things work in the UK, but it seems like NBN Atlas is the de facto national data aggregator, and it takes data from iRecord, iNaturalistUK, iSpot, and other sources.

so then i don’t understand what folks are trying to accomplish by integrating iNaturalist data into iRecord, since this seems to make iRecord an aggregator, too. maybe they’re trying to use iRecord as a way to verify / clean up data before it goes to NBNA, but then do they do the same with all those other data sources? if that’s the direction they’re going, then it seems to me like they need to keep the collection functions of iRecord separate from the aggregation functions. if the verifications are going to be more part of the aggregation than collection side of things then there’s no need to push verifications in iRecord back to iNaturalist.

instead, it seems like what really needs to happen here is that if there are certain known verifiers who make a given identification in iNaturalist / iNaturalistUK, then those will get translated automatically as verifications in iRecord. that should be be mechanism to reduce the duplication of work between the systems, rather than trying to push data from an aggregator back to a data source.

if iRecord is going to become the de facto national data aggregator, then this might make sense, but frankly, it sounds like they are trying to do something different and more complicated – in which case, i don’t think this would make sense, since iRecord would not simply be an aggregator.

fundamentally, iNaturalist is interested in connecting people to nature (and to others who are interested in nature). they explicitly state that they do not want third-party developers to fragment the community. system accounts fragment the community by carving out a portion of the community and putting it behind a wall, subject to a whole different set of rules and mores, and potentially inaccessible to the rest of the community.

2 Likes

This is the aim for dataflow in UK now (sourced from this page ) :


:

I imagine part of the problem is the double-edged sword of having a long history of recording dating back centuries. It’s a rich tradition but perhaps more convoluted and splintered than some other countries as a result.

It’s a gateway for the records to be checked and verified by the recording schemes before it gets passed on to NBN to ensure NBN has as rigorous a dataset as possible.

Whenever people complain on iNat about data quality, forum users often reply that any researchers should maintain and clean the data themselves to be sure its fit for purpose. Well this is difficult on iNaturalist as it exists at present, given you are reliant on other members of the community to have consensus to reach RG before a datapoint can be sent on to GBIF.

They could send the data direct to NBN as they did in another trial but mark it as being crowd-sourced. I think this might be a better solution in some ways tbh - at least for common taxa. But some recording schemes actively want all iNat data for their taxon and want to be able to filter and fix it before it gets sent to NBN in as speedy a way as possible. The recording schemes are all voluntarily run and already say they are maxed out with time commitments as it is - most simply don’t have time to navigate community consensus through tagging in others to agree or help fix incorrect IDs, etc in addition to their existing commitments.

So, no, I don’t think the two platforms are comparable tbh.
iNaturalist is built more with observers in mind.
iRecord is built more with verifiers in mind.

Ok yes… makes sense.

But at least most taxa in UK often have much more than two iders who could actually check all the iNat data and verify it, I don’t see a big problem in it from iNat side, it’s a human work to do.

In more common taxa this might be true, I’m not sure…I can only really speak for UK Diptera.
In UK Diptera, we have expertise active from 3 or 4 of the 30 or so existing UK Diptera recording schemes. For example, Ian (@ophrys) is the leader of the Heleomyzidae recording scheme. Chris (@chrisrap) the leader of Tachinidae recording scheme. Darwyn (@rainieria) covers Micropezidae and Psilidae.

Chris and Darwyn won’t be checking or identifying observations to species outside of their chosen families. Ian does help more broadly on UK Diptera as he is unusually generous with his time, but I imagine he still won’t be adding species level IDs outside the ones he knows by heart or knows he can check with ease.

This is very different to a recording scheme leader who may have access to a reference collection, be familiar with literature and be capable of identification at a much finer level from photos than a generalist quickly dipping into an unfamiliar family. I am the 2nd most active identifier in UK Diptera and I rarely have the confidence/ability to go to species or time to attempt to key from photos. My amateur efforts are certainly not comparable to one of the scheme leaders. I blind agree to other UK scheme leaders sometimes though in order to subvert the system and lend support / encourage the participation of expertise (as I believe the South African community does). But it certainly makes sense to me that iNaturalist will not come across as inviting to verifiers in comparison with iRecord - it’s just asking extra effort of already time-pressed volunteers.

That’s interesting. I wonder how difficult that would be on iRecord’s side - sounds like it would also be complex to implement, no? I realise one can just import IDs by specific users, but that would involve a lot of mapping to do it manually for each expert identifier. If there is an option within the API / projects / network nodes which would make this easy to implement though then I could imagine that being a plausible route.

But if already existed people joined iNat you’d have many more, ofc. there’s always only one or a few true experts on a particular family, but it can be filled in just by numbers. As you said, UK has a long history of such things, so those people are real.
Why exactly spending time on the same thing they already do is not as inviting? What’s the difference between places where they do that? Photos are the same everywhere. It strikes more like experts don’t care about those who create the data they then use, so they wait for filtered content and thus force people to use multiple platforms to get their attention. They don’t want more work, but it’s inevitable, it will grow no matter what. As mentioned iRecord only get RG obs., but how can they be RG if there’s nobody to id them? It forces you to blindly agree, which shouldn’t happen, so there’s a clear problem.

1 Like

Not sure what you mean by “filled in just by numbers” …but most UK Diptera recording schemes only have a single person invested in doing verification for a single family. Even if the other 27 UK scheme leaders joined, they wouldn’t support species level IDs outside their own family unless they participated in blind-agreement.

This is the exact inverse of what some UK verifiers are saying on Facebook. Some feel iNaturalist and the observers here don’t seem to care about how much work it is for verifiers to deal with iNat data. Most verifiers would much rather everyone used iRecord than multiple platforms. That’s why there is significant opposition to use of iNat.
I think there must be compromises to be found to appease both communities.

I agree - there is a problem - but from my POV the problem is with iNaturalist in this regard. I can’t be simultaneously against conscious blind-agreement with expertise for the benefit of the community …then participate daily in a system where the large majority of users anyhow blind-agree with any identifier who comes along, as they don’t know any better.
But anyhow - this aspect is pretty tangential and a well discussed topic, so we should probably start another thread if we really want to discuss the rights and wrongs of blind-agreement with expertise.

2 Likes

Sure harder taxa would be less ided (I think it’s something we can live with), but it’s not only insects, there’re e.g. plants where most people are actually more generalistic in their id abilities, as diversity is lower.

I don’t really know what they talk about, I think you know too that looking at regular contributers there’s no sign of disregard to iders, there’re not that many of them to even do that, each expert is as good as gold.

I think we can ask moderators to move these messages to another topic, so this one will be clear.)

1 Like

Absolutely - it’s just a whole lot of misunderstanding.
Those who only use the iRecord side of the bridge only see the limited view of the community the data iRecord imports provides. Whilst anyone who only uses iNaturalist and is not an iRecord verifier will not be able to see the difficulties from their perspective. Most of us can’t choose to experience life as an iRecord verifier, so we just have to listen to what they are saying as best we can. I try and counter misinformation when I see it…but we have to hear the truth in the issues they are raising as well.

1 Like

i don’t think this should be particularly difficult. each verifier should have an account on the iRecord side, i assume. they would need to make an account on the iNaturalist side, too. then on the iRecord side, they would need to have a function that allowed them to input their iNaturalist login. that would take them through a quick iNaturalist authorization flow just to make sure that the iNaturalist login they supplied matched the login that they signed into iNat with. from that, iRecord could get and store the iNat numeric user ID. then when iRecord pulled data from iNat, they could see if any observations had IDs associated with iRecord verifiers, and then those observations could be marked as automatically verified, assuming the verifier’s ID was also the observation ID. this would mean that for any records originating in iNat or iNatUK, ideally you would want the verifiers to go over to iNat or iNatUK and verify the observations there. otherwise, i guess they could just verify it on the iRecord side without pushing anything back to iNat. one other option would be to have a mechanism in iRecord to agree to an observation ID in iNat via the API using the verifier’s iNat login, and then that would flow through whenever the updated record was pulled back through from iNat to iRecord.

1 Like

Ah right …hmm…but then this still requires blind-agreement / twice the verifiers.
I don’t believe most verifiers would choose to use iNaturalist directly if it remains twice the work to resolve an ID. It would have to bypass this to be viable.

any sort of one-way street is problematic too.
its a missed opportunity, but it also limits dialogue which prevents the community’s understanding one another and leads to a lot of confusion and frustration.

not sure I understand what you mean here. They wouldn’t see it in iRecord unless it’s RG…
any IDs which are sent upstream would either be agreements (not that meaningful) or disagreements which would push them out of the RG pool and require re-verification/blind-agreement by community.

and I wonder if an updated record would even be pulled back in?
I mean I think iRecord only pulls it in once. I guess they would have to decide to check the ID number against previous IDs to monitor change. At the moment they are probably just making sure they don’t pull in the same record twice under any circumstances.

Perhaps something like this feature request to help filter obs into projects by specific identifiers might help navigate this space.