There is a fix deployed for this behavior that is now live on ACW. When selecting ‘My Data’ for determining a matching set we will now check against the submitterID for an encounter instead of the submitter list. If the submitter list did not contain your username, even if you had ownership of an encounter it could return zero results for a matching set. Discrepancies here could have produced an artificially small or empty list of matching candidates.
The identification system does a fallback comparison if provided no candidates where it compares against everything of the appropriate species and viewpoint in the system. This is why the results could be large and not limited by location or user- the ‘My Data’ query inaccurately turned up nothing. This also explains how the large candidate set number could be the same for multiple examples you provided.
We think that this is the reason choosing ‘My Data’ for a matching set could have unpredictably resulted in incorrect matching sets.
The internal issue ticket closed by this is WB-1626.
Since it is only a difference of one and I did not see this effect I suspect some stale caching either in the database or the browser.
I also looked for Lycaon Pictus in the location ID Botswana. That is the location ID for this encounter, although I see many more for the broader location ID ‘Africa - South’. There are 716 suitable encounters for that query, and 714 of them belong to Gabriele. It is entirely possible that you would return nearly the same or exactly the same matching set whether you set “My Data” or not for this matching job.
Also, I’m not sure we’re referring to the same issue?
If you look at the Bongwe example above, we found more candidates when My data was selected (4113 candidates) versus 110 candidates when I ran matching against the whole database (no match criteria selected), under my admin account.
I think the ‘My Data’ query returned zero candidates for this specific example. If it returns zero candidates and sends the job to image analysis anyway, then image analysis gets to decide and sometimes the “Just Try Anyway” matching set can be quite large.
Also, what’s the reason for the same annotation of the same individual to be offered as the only match results for 4 different individuals? That seems like a strange coincidence?
It’s a little weird but not unheard of. I’d guess that out of those extremely small matching sets Belarus is truly the best candidate. His encounter has a very high quality images of left and right viewpoints.
Hi @Colin - @jason, Paul and I just had a chat about this and we agreed that adding code to tell the system to match any IA class that starts with “wild_dog_” should be matched against all other “wild_dog_”.
For any IA class that starts with “wild_dog+”, they should only be matched against other “wild_dog+” IA classes in the future; however, at this time these IA classes with the “+” sign are all tail parts and these are currently set to “false” or to not be matchable. For now, we don’t have a need to change this to allowing tails to be matchable to each other, although we may in the future. But for now, we can ignore the matching between tail classes because of this.
I hope that makes sense! Thanks to both of you for working on this. We like the solution!
