What is the entire URL out of the browser, exactly where the error occurred?
No error occurred. But here’s the link to the page that gave rise to this question:
Can you describe what the issue is you’re experiencing?
We ran matching on this encounter: 4914337d-5447-4f6f-b628-b7fd07029824.
The researcher knew which dog was in the encounter and knew that this dog is in ACW as “Okavango”. But Okavango was not in the first 12 match results served up and none of the dogs in the first 12 results matched the target.
So we’re wondering a few things:
Is there a way to “refresh” the match results served up by the system?
What’s the max # of match results that can be set?
Any thoughts on why Okavango was not a higher match result than Ginkgo who was offered up as a low probability match @ #12.
This experience and others that same day gave rise to a couple of feature requests we logged at that time:
Have a way to mark matches that the system offers up as “not a match” to the target so they don’t get offered up again. This would be similar to the manual process of putting aside photos that are clearly not matches for the new photo in hand.
Have a way to retain a match made between 2 non-ID’d individuals. We have A LOT of images of African wild dogs and cheetah, for example, because of the high volume of tourist contributions. Which means that the system may serve up many un-named individuals in the match process that ARE a match, before it serves up the actual ID’d individual that matches all of those other pics of the same animal. Being able to connect all the matched animals before they are matched to an individual would reduce iterations on the matching process being run repeatedly for a single unknown.
Being able to “refresh” the results shown is a shortcut option that may not address the issues we ran into but I guess it’s just another way of trying to solve the problem of many many more photos of un-ID’d animals than ID’d animals and seeing more of the former being matched to each other before the correct ID’d individual (such as the example of Okavango above) is offered up by the system.
A lot going on here. Let me know if I miss anything.
You can refresh your matches by going to an annotation and, from the Gallery menu, select “start another match”
Using this option, you can set parameters that will make you more likely to get the result you expect to appear in the listing.
Having a way to set that two annotations do not match is something that is planned for next gen. The current UI is strained enough with information that we can’t shove in the functionality, and the back end would require massive overhaul to maintain the persistence of not-matching.
Have a way to retain a match made between 2 non-ID’d individuals. I still do not understand what the value is in not providing a name for these matched-but-not-ID’d individuals. The system supports multiple names and names can be updated.
Thanks for the reply. #1 is very helpful and it’s good to hear that #2 is in the pipeline for next gen. Re #3: I think it’s probably best to have a chat about this one but I’ll try here to explain a little further why this is so important to ACW users and I expect in other Wildbooks that have the same kind of dataset.
The dataset composition is key here. We have, and will have tens, even hundreds of thousands of images per species in which the animals are unidentified. We will have maybe a few dozen marked individuals. Lion & elephant datasets will be even more skewed to unknowns. So when a user sees 2 unknowns that match, the instinct is to capture that, obviously. If the 2 unknowns are not a match to any indiv. in ACW, great, create a new ID and all’s good.
But what if the 2 unknowns are a match to an indiv. in ACW but that indiv. is not offered in the matches presented? There’s no way for a researcher to know that they match a known indiv. except if it’s offered in the matches run. The challenge then is twofold: 1) how to know to re-run matches and how many times before one can be sure that there’s no match in the system? 2) what if the researcher assumes there’s no ID’d match when there is, and proceeds to create a new ID? Now we have multiple ID records for the same individual. Assuming this gets discovered at some point after that (which is not a given) all encounters from one indiv. have to be un-linked from it and then connected to the other known indiv record. The steps to do this are several and even more if there’s a social group connection. Not connecting 2 unknowns bec of the hassle of un-link/re-link process is a waste of time bec the researcher would then have to re-do their visual inspection of matches presented that they’ve already inspected and confirmed, or rejected.
Historical data is extremely important bec of the patterns and trends it can show researchers, including the impact of intra-species interaction as well as the impact of human encroachment, etc. So we can’t not import ‘old’ data. So our volumes are huge and will get huger, skewed to unknowns, over ID’d individuals. I hope that helps for now; let’s discuss further on our next call.
That does help give a bit of context as to why you would want that. I’m going to mark this resolved since there’s at least an answer in refreshing matches. I’m still working on documenting the match process and best practices around it, so when I get that published, I’ll be sure to make sure to send the link.