Please stop retiring Historical Records and revert previous retirements
Background to this request is on https://community.familysearch.org/en/discussion/147746/another-incorrect-retirement-of-a-not-duplicate-record plus numerous others.
There have been numerous examples where Historical Records have been retired because they are duplicates of others - the problem is that in a number of cases, they are not duplicates.
I just found this one by chance (it's my 3G GM) and felt I ought to highlight it as an additional incorrect retirement of a Historical Record in case it helps persuade "the management" that there really are issues.
https://www.familysearch.org/ark:/61903/1:1:NFTN-BWY has a legend at the top saying "This record was a duplicate and has been retired. We recommend using the most current copy". The "View Current Record" link takes me to https://www.familysearch.org/ark:/61903/1:1:NYDG-MZR
Both are text-only records in the collection England Births and Christenings, 1538-1975.
The essential problem is that the two are not duplicates. One has a Birth Date and the other doesn't. You will probably guess that it's the one with the Birth Date that has been retired, and the one without is the "most current copy".
Request 1 (fix this one) - Please unretire the one with the Birth Date.
Request 2 (fix the future) - In future, please do not retire records where the data content is different.
There are several different types of erroneous duplicate withdrawals. In this case, the film / DGS number is identical for both retired and most current copies, suggesting (but not proving) that the same original has been indexed twice - either way, the contents of the two index records are different.
I know of another case recorded in the Community where it was decided that a Parish Register (PRs) and its corresponding Bishop's Transcript (BTs - copies made by the church) were duplicates and so one was retired. This should never have been done as the source documents were different physical objects. Yes, BTs are usually duplicates of the corresponding PRs but every so often the BT is different from the PR and it is totally unfair (and impractical) to expect anyone to go through all the records individually to identify genuine duplicates.
Request 3 (fix the past) - Because of the number of cases where the contents of the index records are different, I believe that the safest option is to identify all records that have been retired as duplicates and unretire them all and I request that FamilySearch does so.
Comments
-
When the suggestion of retiring records was raised (about 6-7 years ago?) I was inclined to agree with the idea, whereas some users were vehemently against it. It was then decided by "management" (yes, FS managers used to participate in these public forums at that time) that it would be too risky an exercise - ly due exactly to the reason now being clearly illustrated.
If any manager / FS employee with any authority is following this thread (the moderators insist all these ideas are read by someone who can take action / escalate to someone who can deal), please take heed and ensure no further retirements are made without the records being thoroughly assessed to see which genuinely is the one that can be safely retired.
Though, better still, put a halt on the whole process, to ensure there is no further danger of vital information in indexed sources being lost due to the unnecessary retirement of records (i.e., them no longer appearing in results produced at Search Historical Records).
6 -
Like you, @Paul W, I was inclined to think that it would be perfectly sensible to retire duplicates. The issue is that, to paraphrase words from one of our esteemed co-workers, their definition of "duplicate" is not one with which I am familiar.
It's as if they have tried to see whether entries are "logical" duplicates. That's immensely more complicated than checking for "physical" duplicates by asking is it the same URL, the same index contents, the same film etc, etc, etc.? There are instances where (as per my 2nd post on the thread containing the background) even I can't guess what the truth might be so, short of examining every record in a collection, the safest option is not to withdraw anything.
4 -
Your concerns have been escalated and someone will look into both this request and the post at https://community.familysearch.org/en/discussion/147746/another-incorrect-retirement-of-a-not-duplicate-record. Thanks for providing this info.
2 -
Thanks @Maile L
1 -
Another example:
https://www.familysearch.org/tree/person/sources/G3LW-ML6 gives this retired message for the single source, the CURRENT RECORD link (originally https://familysearch.org/ark:/61903/1:2:9S3Y-2JH) gets redirected to a different "copy" of this record (https://www.familysearch.org/ark:/61903/1:1:JHSV-JMZ) which does NOT include the fathers of married couple, i.e. it does not contain a reference to Peter Christian Blech which has the retired source attached.
Please stop this, it creates a lot of headaches.
Matthias.
3 -
This whole conversation horrifies me. The first time I saw a source with the message that it would soon be retired, I thought it was going to be a mistake. Now I see my gut was correct. Ugh. I gave this another uptick.
3 -
I came across this issue for the first time today and have also been horrified reading the multiple threads detailing the problem.
The amount of potentially lost information from the fallout to this is alarming. Think of all the stub PIDs that were generated off these now retired records alone, that may have since be merged with duplicate sourced PIDs. Unless you know to mine down through the change log of a deleted PID, that information could be lost for good.
The system for retirement seems haphazard at best.
I came across this retired record today, which not only contains baptism information but also a death date.
https://www.familysearch.org/tree/sources/viewedit/M4JP-H37?context
This is the link to the "Current" record.
https://www.familysearch.org/ark:/61903/1:1:J3HD-2FP
The only similarities are the individual's name (Charles Read) and baptism date (02 May 1819).
Not only is it NOT a duplicate, it is an entirely different record.
The mother's names are different (Elizabeth vs Rebecca) and the two records are from ENTIRELY DIFFERENT COUNTIES?!? (Hampshire vs Hertfordshire).
There is also a benefit to having duplicate records across collections that I haven't seen mentioned anywhere else, and that is the ability to fact check spelling/dates etc across records. Transcription errors in indexing does seem to be an problem I come across fairly regularly, and multiple same or similar sources is a big help in troubleshooting that particular issue.
I really hope this issue is addressed. It would be a tragedy to lose all these erroneously retired records and the unique information they contain.
4 -
I have to say that I am shocked by the example of a so-called duplicate in the post by @RaniM (for which many thanks).
In truth, I am not opposed in theory to the retirement of genuine duplicates - providing that they are genuine, total duplicates with the same spelling of all names, the same original image (if provided), etc. Err - like "Duplicates".
But these two records are not the same by any stretch of the imagination. What disturbs me is that the degree to which they do match (and don't match) is horribly reminiscent of the poor quality hints for merges or source attachments that I used to see some time ago, where two identical names (e.g. child and father) seemed to count for more than the fact that the other people and the places were totally different.
If some sort of software algorithm is automatically proposing stuff for retirement based on such a poor algorithm as this appears to be, then we are in deep trouble.
There appears to have been no informed human intervention at all, otherwise FS could never have come to the conclusion that the two source records were duplicates as the payload data is just utterly different and you don't need to be a Jedi in British parish records to see that.
@Maile L - I know you said that you had raised this already but this angle is so utterly different to everything that I remember seeing before on this topic, I genuinely wonder if someone has started another process running?
3 -
What are we looking to solve by retiring records?
Is it like when I have 17 marriage records with identical data (and I attach all of them to prevent them from seeding new duplicates)?
0 -
Here are another couple of retired "duplicates". Fortunately, one can access the film through clicking on the image, but it's sad these won't be found via https://www.familysearch.org/search/ any longer.
Here are the respective links for the sources, minus the images, that have been kept on the database:
https://familysearch.org/ark:/61903/1:1:JM63-L9Y
https://familysearch.org/ark:/61903/1:1:NJRN-XQZ
Just found I can add the links to the above (screenshots), after all:
2 -
The 1836 marriage on https://www.familysearch.org/ark:/61903/1:1:NFDG-S4X is from a Bishop's Transcript.
This is an alleged duplicate of https://www.familysearch.org/ark:/61903/1:1:NJRN-XQZ However, that is from a Parish Register. As I've said before Bishop's Transcripts and Parish Registers are completely different documents and the one can never be a duplicate of the other. They are different source documents, compiled at different times. The BT is supposed to be a copy of the PR but is not always identical - on occasions the priest made corrections to the BT but not to the original PR. It's like saying you don't need a von Karajan recording of a symphony because you've already got a Simon Rattle version...
If the processes for identifying alleged duplicates cannot distinguish between BTs and PRs then the process needs to stop right now and be reversed.
3 -
What is seriously weird is that if you look at the PRs for Manchester Cathedral in the Catalogue, (see https://www.familysearch.org/search/catalog/40069?availability=Family%20History%20Library ) you will find a list of films that have images available on the open internet, but no index, followed by a series of films, which appear to duplicate the previous lot because they have titles with a suffix "(another filming)". These (according to the icons) have indexes but no images on the open internet - the reverse of the original filming.
I have no idea what the rights are for those - these original PRs are held (from memory) by Manchester Record Office at Manchester Central Library and are on Ancestry. But if those two sets of PRs are OK from a contractual viewpoint (if) then I would be sympathetic to retiring one set, providing the other set had both indexes and images on the open internet. I still think it's very courageous to try retiring one set.
Whereas the original BTs are held (from memory) by Lancashire Record Office at Preston and are also on Ancestry. Perfectly possible that the PRs and the BTs are under different contractual agreements. As I said, BTs can never be duplicates of PRs. Yes, it is complicated. No it's not working...
2 -
I saw an example the other day. Sorry didn't keep a copy, but I can probably find it again and do so. It was 2 versions of a birth record - one is a certificate and the other is a ledger. They are NOT the same record and do not contain the same information. One was marked as a duplicate being retired. Both are limited to access only at an FSC.
Edited to add: Ah! I did save copies. Since they are restricted access, I won't post here, but I have the details in my file.
1 -
Yes, sorry I implied the image-attached versions were of PR entries, rather than from the BTs. I guess there could be some contractual reasons with these examples, but I would think it more likely that this is part of a general (bot?) exercise, which (like the auto-standardization process) has gone horribly wrong.
3 -
I received this response regarding our inquiry about retiring records:
"The process to remove duplicated records did what we needed for most of the records. Unfortunately, given the size of our records collection it had issues with some collections and didn't perform as well. We are aware of the issues and there is a longer-term plan being developed to correct the issues caused without reintroducing the duplication issue. We hope that this solution will create a better experience for everyone. In the meantime, please be assured that all of these records are still in our collections and stored in our databases. Also, any records that are attached to our tree are still attached and accessible from there. "
2 -
In one of the several discussions we had about this issue over the summer, it was suggested that we should just delete the duplicates from the profiles to which they are attached. At the time I said that was not a good idea. And, the answer Maile just posted shows just that. "...any records that are attached to our tree are still attached and accessible from there. "
1 -
Yes, it's true these sources don't disappear from the profiles of those individuals to whom they have been attached. Nevertheless, it is sad that (there not being any contractual issues involved here) such useful records are no longer available from the Search results screen(s).
I wonder if FamilySearch manager Robert Kehrer is still around. When suggestions about withdrawing "duplicate" records were first made some years ago (some users wanted to avoid "unnecessary clutter" in the Sources section), he warned us of the possible consequences of retiring records that might contain more detailed information than the ones that would remain. He was very wise to suggest that such an exercise should be undertaken with extreme caution, but, sadly, his predictions appear to have been disregarded.
4
