duplicate label transfer: There might be a problem with the dedupId when it is copied NOT from the pivot record to the current record, but from the current record to the pivot record (see DeduplicationService::compareSet)
Reason
In FP and FN the couple where id == dedupId is counted as FN or FP, but it should be skipped IF the only other couple was an error.
E.g. for FN:
| id |
dedupId |
Counted as FN |
Remark |
| 304 |
304 |
Yes |
WRONG: Should not be counted as FN |
| 31863 |
304 |
Yes |
GOOD: Should be counted as FN |
| id |
dedupId |
Counted as FN |
Remark |
| 296 |
20257 |
Yes |
GOOD: Should be counted as FN |
| 20257 |
20257 |
No |
GOOD: Should not be counted as FN |
| 33023 |
20257 |
No |
GOOD: Should not be counted as FN |
The analysis files use lowerID - higherID order. If 2 records (higherIDs) are FNs for the same record (lowerID), only the first couple is reported. For the records "25459 - 25452" and "29789 - 25452" in SRS_Human_to_validate, only the last one (25452 - 29789) is shown in SRSR_Human.txt_FN_Analysis.txt. The same for 26855 - 26854 and 26856 - 26854
duplicate label transfer: There might be a problem with the dedupId when it is copied NOT from the pivot record to the current record, but from the current record to the pivot record (see DeduplicationService::compareSet)
Reason
In FP and FN the couple where id == dedupId is counted as FN or FP, but it should be skipped IF the only other couple was an error.
E.g. for FN: