Retired Records

LegacyUser

ohnocrissyee said: I have notice you are retiring duplicate records ,great idea, BUT ! there was one that grandparents were added in the information and that one is a great deal more help then the one that is being used, which only has the couple names. That makes it to easy for mixed up families . Keeping the one with the most information I feel is the best . example: is this marriage record, Would had been the best one to have kept .https://www.familysearch.org/ark:/619...

LegacyUser

Ronald Tilby said: Someone at FamilySearch needs to determine how they chose which record to retire. Because in this instance, they definitely retired the wrong record.

I encourage everyone to follow the link in the above post and compare the retired vs current record.

LegacyUser

Howard Norman Camp said: I agree that the RETIRED record should have been retained and the other duplicate should have been the one retired. Please look into the algorithm to make sure that the record with the most information is retained. Thanks.

LegacyUser

Paul said: I assume this might have something to do with the conditions of a revised agreement, which now only allows for the lesser detail to be displayed in FamilySearch. However, if FamilySearch has retired the collection in question, without there being any outside influence, it would be quite ironic. Users are constantly requesting that "duplicate" records are retired (as in when duplicate filming has been subject to duplicate indexing), yet as soon as this does happen the wrong set is chosen for retirement!

LegacyUser

Adrian Bruce said: Um. Without knowing why the retirement took place at all, I find it difficult to have an opinion. Given that this specific record has an image available - albeit you have to scroll through to find it - no data has been lost. On the other hand, it will take a lot longer to find the now parent-less index record because the criteria that we can search on have been reduced.

I wonder if the reason for withdrawal is something to do with how the source-linker was able to work with "Spouse's Paternal Grandfather's Name" and "Spouse's Paternal Grandmother's Name"? Quite badly I suspect!

It would be nice to know...

LegacyUser

Kurt Kastner said: I know that COVID-19 makes everything difficult. But as a first step it would be great to hear that this subject has been recognised as a problem.

In almost all cases which I saw up to now, the more informative record was retired and the less informative record was kept. In christening records birth infos are missing, in marriages the bride's/groom's parents vanish.

Please have a look on this!

Example: https://www.familysearch.org/ark:/61903/1:1:VCYL-22M

LegacyUser

Kurt Kastner said: I think this was a problem with older source linker versions. The current (Aug 2020) version works fine with grandparents.

LegacyUser

Paul said: Excellent example, Kurt. Can anyone explain what the "System origin VR" means in the retired record, compared to the "System origin ODM" in the current one?

Any specific reason for the replacement of a source with one containing much less detail would also be appreciated.

LegacyUser

Adrian Bruce said: Hmm. I see that it says "This record was a duplicate and has been retired."

Given that the original (now retired) appears to have had 14 items and the new has just 8 - perhaps FamilySearch can explain the meaning of the word "duplicate"? It's certainly a meaning with which I am not familiar...

NB - to forestall comments - if a legal / contractual agreement has led to the retirement of one in favour of the other - I accept that, but it's not what is being stated here.

LegacyUser

A van Helsdingen said: I thought the this collection was from the IGI, so should be fairly static. Nevertheless, there will still be contracts and the record custodian (or a third party such as Ancestry.com) could have renegotiated it.

LegacyUser

Jeff Wiseman said: Have a look at part of these two side by side:



As you can see they NOT the same index source (which we have already figured out here). They are two distinct sources for index data, each with it's own persistent ark type URL, but they BOTH have been indexed from the same identical image source.

Also they were both in the same indexing project batch as well. And if I understand correctly, the fact that they are both marked with the same 18 March 2020 date would seem to imply (along with the same batch number) that they were both created on the same day. So there seems to have been two different index records created from the same identical image source on the same day and they are "Retiring" the one that seemingly has the most useful information in it.

So if someone does a search for a marriage record of a Christian Daub with a father and mother named Georg and Magdalena, the parents names are now useless in the search? Or will the "Retired" record be found and redirected to the other record?

Since both records have persistent URLs, you can't just stop supporting the URL for the "Retired" record. At least, that's what I thought the rules were for these ark type URLs.

Also, if you find one of these attached to a person's source list, are you supposed to detach it? Are you guaranteed to already have the other "Current" hint available to replace it with? If you detach it, will it be thrown back at you as a new hint again? (I've seen that happen on older ark type URLs that were updated as well-the old hint that you threw away just kept coming back over and over)

It would REALLY be nice to know exactly what FS means by "Please use the current copy" in the Retired record banner. And why are we not supposed to use seemingly useful data in the index?

I can only assume that if those extra names disappear from the record, they will also disappear from the source linker. But then the banner also says it is a duplicate, when it appears that it is not!

LegacyUser

Adrian Bruce said: "if someone does a search for a marriage record of a Christian Daub with a father and mother named Georg and Magdalena ... "
I'm starting a new Reply for this in case I'm missing the point but...

I tried to search "Name: Christian Daub Father name: georg Mother name: Magdalena Record Type: Marriage " filtering down to collection "Germany Marriages, 1558-1929"

Nothing appears that looks like this marriage. The one that Kurt attached.

I removed the parents' names and added a marriage date of 1878 to get the right event to the top - more or less - and it explicitly says "No Results for Name: Christian Daub Marriage Year (Range): 1878 - 1878 Record Type: Marriage" (my emphasis)

Here is the URL for that last search:
https://www.familysearch.org/search/r...

So where is that marriage on any search? I'd be interested if others (particularly Kurt) get any results with that URL. I can see other entries in other searches for "Germany Marriages, 1558-1929".

I can follow Kurt's URL and see the screen starting "Retired Record
This record was a duplicate and has been retired. Please use the current copy". And I can use the link there to view the current record quite happily.

But I can't make that record appear in a search!

Has the retirement facility sabotaged the search? Or is it simply an effect of the privacy rules applicable to that part of "Germany Marriages, 1558-1929"? (In which case, how can Kurt find them?)

I also tried using the catalog to look at a couple of the DGS numbers in this area:

4037536 relates to Karlsruhe's Kirchenbuch, 1810-1962, specifically it's "Heiraten 1843-1869 -- Tote 1810-1857 -- Heiraten 1870-1961 -- Taufen 1853-1870 -- Tote 1858-1870 -- Taufen 1870-1937 -- Tote 1870-1962 -- Nachtrag: Taufen, Heiraten, Tote 1810-1869 (Seite 184-185)". If I try a basic search just quoting that film number, I get "No Results for Film Number: 4037536". Note this is not a response about too much data.

I get a similar result "No Results for Film Number: 102078065" - this film is "Taufen 1810-1851 -- Heiraten, Tote 1810-1843" for Karlsruhe.

So - what is going on with these searches? Am I totally misinterpreting the outputs?

LegacyUser

Kurt Kastner said: 18 March 2020 is the date of the last update of collection "Germany Marriages, 1558-1929". Both index records are much older. One was attached to the groom Christian Daub in 2014, the other in 2016. The system does not present the the creation date of index records to the user.

LegacyUser

Tom Huber said: This may be in response to an issue I posted in this forum a number of months, if not a year or so ago, whereas the same images had been indexed twice, with one index presenting information not present in the other, and that the indexes were released just days apart.

I spent almost no time working with the two indices to see if they were consistent in what I had noticed. So it is entirely possible that one index was "retired" in preference to the other when some entries were more complete in the retired index and some entries were more complete in the other index.

That, of course, presents a problem when deciding which index to "retire". If this is in response to the issue I reported, then what should have been produced was a composite index that takes the most complete record from both and produces a new index wherein each entry made was the one that was the most complete -or- a composite of the same entry so that it contains all the entries.

LegacyUser

Jeff Wiseman said: Thanks for that clarification. I've wondered about that date before. It seemed to always be associated with when a citation was first created. But then when the text content of citations started changing (e.g. during URL updates) it just got confusing.

LegacyUser

Kurt Kastner said: I have the same problem with many films originally photographed at "Karlsruhe, Germany : Evangelische Landeskirche". They are contained in the collections

1. Germany Births and Baptisms, 1558-1898 (https://www.familysearch.org/search/collection/1473000)
2. Germany Marriages, 1558-1929 (https://www.familysearch.org/search/collection/1473009)
3. Germany Deaths and Burials, 1582-1958 (https://www.familysearch.org/search/collection/1494474)

These are traditional FamilySearch collections and have been searcheable for all users since a long time. But the films are also contained in

4. Germany, Lutheran Baptisms, Marriages, and Burials, 1500-1971 (https://www.familysearch.org/search/collection/3015626)

I believe that this collection originally came from Ancestry.com and search is restricted to church members. However if a church member adds such a record to FamilyTree, the other users have access to it. Ancestry does call it "Germany, Lutheran Baptisms, Marriages, and Burials, 1500-1971" (https://www.ancestry.com/search/collections/61229).

I suspect that the attempt to hide collection 4 (ancestry) from non-church-member access lead to the result of also hiding the records of collections 1–3 (FamilySearch).

LegacyUser

Kurt Kastner said: Do you know the subject of the other thread, or even better a link?

LegacyUser

Jeff Wiseman said: In any event, information appears to have been LOST by this change. Before, the original marriage record provided proof of the parents for both the bride and groom. Now the parent child relationship evidence has been thrown out by retiring this record.

I saw something like this a few weeks ago when an update of a bunch of ark type URLs resulted in some historic records (again, marriage records) just disappearing when they were the ONLY records that showed proof of several parent-child relationships. Notes that I had regarding the parent-child relationships were then meaningless since they referred to records that were no longer attached and could not be found in the system.

Anyway, something is definitely screwy.

LegacyUser

Tom Huber said: I reported it 9 months ago .. the link is https://getsatisfaction.com/familysea...

LegacyUser

Tom Huber said: Interesting. that reported problem was not resolved. both entries are still there and the indexes still show the same thing. -- This happened to be draft records, not marriage records.

LegacyUser

Adrian Bruce said: Sounds possible.

Anyone with both member and non-member access care to try to search for these entries? (Or can confirm otherwise...)