An excessive amount of identical sources
LegacyUser
✭✭✭✭
Mike said: Looking at Alda R Huston LTGT-F2C and Kenneth Boatz there are 2 copies of their marriage record attached to them already and an additional 10 IDENTICAL records to be attached. Roy Swigart GWB6-GYX has a similar issue as do many people who married in Washington state. Its great that they have been micro filmed and digitized and the computer software can find them. But, can't you write a program that will consolidate them and eliminate or merge them???? Unfortunately, this is NOT an unusual situation. it leads to lots of wasted time, energy and storage space. If you want us to merge people I would like you to merge sources. Thank you. Mike
Thank you for contacting the FamilySearch support team. Your support case #07724340 has been updated.
Thank you for contacting the FamilySearch support team. Your support case #07724340 has been updated.
Tagged:
0
Comments
-
Virginia Florence Horvath said: Many of the sources that I have run into are not true duplicates, the information may be a duplicate but the actual sources they come from is different. For example in Iowa a marriage record is recorded at least 4 times (the certificates and license), an index by date, an index by Groom, an index by Bride. Then there are unknown number of indexes recorded from the state records that are published in reports, books, private and public collections. All of these sources lead to the original state records but are different sources of the information. It is important to record all of these sources, yet some are more accurate and much closer to the original state record of the marriage.
I think rather than writing code to remove/hide sources that appear to be duplicates it would be much better to display the quality and type of source. Original/Derivative Primary/Secondary0 -
Jeff Wiseman said: Ok, in addition to the 2 sources already attached, I looked at the first 6 of the 10 hints currently on Alda Huston. You really need to look much closer at the sources themselves and not just the extremely limited information that shows up in the sources linker.
All 8 of those citations and hints are for totally different sources. And I am NOT talking about the digitally indexed data from those images. The images themselves are for completely different documents!
Although they all provide some information about the marriage between Alda and Kenneth, they are all different documents. This is the same in how family groups represented in a Census can also show up in an obituary. When I looked, I found each the following different documents (i.e., sources):
1. The (paper) index of marriages for females
2. The (paper) index of marriages for males (already attached)
3. The application for marriage license
4. The (paper) index for female marriage licenses direct
5. The (paper) index for male marriage licenses direct
6. The marriage register
7. The marriage return (already attached)
8. The marriage certificate
This is a well documented marriage. But note that the most critical source (i.e., the actual Marriage Certificate) is NOT EVEN ATTACHED to the person records at all!
Each of these documents contains slightly different information regarding the couple and they ALL need to be examined and attached. In fact, if I remember correctly I saw one or two items that disagreed between some of them. You will need to go in and understand why any differences exist.
Also since it appears most of those sources all came from the same collection, the automatic Title generation that FS uses has given them all similar titles. As you attach them, you will need to change the titles to something more like the names I used in the list above so that the next person to come along isn't going to assume that there are 8 identical "marriage" sources (like you just did) and will immediately recognize that there are at least 8 DIFFERENT sources each documenting some aspect of Alda and Kenneth's marriage. Also, with that much information and solid sources documented and attached, it is very unlikely that some hit-and-run genealogist is going to come along and break up or modify your well documented couple relationship for Alda and Kenneth.
Note that the indexes marked as "(paper)" are just that. They are indexes on paper of some of this other documents. We use digital indexes to find source images, but back then many places used paper indexes to find actual records (sort of like a table of contents contained within a book allows you to find what page a specific chapter or picture is on).
Since these are all discrete sources, "merging" something like the paper index of marriages for females, with the register of marriages for that county would be totally unreasonable. They are not the same thing. They are apples and oranges. That would be like trying to merge the 1900 US Census with a person's obituary simply because some family member srelationships appeared on both of them!
Now I didn't look closely at the remaining 4 hints, but I recognized a particular type of data problem on one of them. So it is entirely possible that there MIGHT be a true duplicate there because of some bugs in tools that FamilySearch ran in the last several weeks that was supposed to update the ARK type persistent URLs on marriage indexes--see my last two entries in the following discussion regarding this problem which hasn't yet been resolved:
https://getsatisfaction.com/familysea...
And one last thing. … [truncated]0 -
Paul said: Jeff has given an excellent analysis of your specific issue. From a more general point of view, yes, there are many sources that do contain virtually identical information and, in theory, one or more of these could be easily "retired". This was indeed the intention of FamilySearch engineers a few years back, but I believe they found it too difficult to create a computer program that was able to check out the different sources and evaluate which held the least important data.
I have used similar arguments to you in the past and still get annoyed at having to attach several sources that genuinely do contain the exact same detail, but as Jeff has illustrated, this is far from being the case with regard to the records you are dealing with here.0 -
Robert Wren said: Yes, an excellent analysis, Jeff (as usual). My brief(er) analysis showed the same results.
I believe it's FAR better to have MORE sources (&indexes) that NONE.
Users need to remember that all of these 'excess' index/sources need to be attached to minimize PID duplications by others who might use them to create more new DUPLICATE persons in the FSTree.
Hopefully, at some point, FS will create Source 'nesting' to minimize the number of 'duplicates' showing in the the PID source lists, as has been suggested in this forum before.0 -
Jeff Wiseman said: The ironic thing about the nesting is that true duplicates are typically rare and are usually created by accident. It would be better for FS to just not create the duplicates in the first place. When changing over to ark type URLs though, this can also be avoided by correctly updating all attached citations for the old URLs. Unfortunately errors in the tools that were used to do this have resulted in many true duplicates being created.
So with so few sources not being true duplicates, the ability to "nest" them would not normally be needed. But here, there is a CATEGORY of sources (i.e., marriage related sources) that could be collected into a group/folder of some type in the source list. But I would MUCH prefer to just try and tweak the titles on sources from different physical documents and then place them next to each other in the source list.
(And make the source lists much more efficient to search through without a bunch of "fluff" data being displayed wasting many lines of space that force the lists to take up 5 times as much space on the screen as needed--i.e., the way it used to work before it was "improved")
But that works fine with the "Custom ordered" display since it is ideal for CATEGORICAL ordering of sources based on their type rather than a date that has been pulled from them. If a person were to choose to set a "Source Event Date" as the marriage date for ALL of those sources (certificates, returns, bans, registers, and all of the paper indexes that may exist for each of them) in spite of the sources being created on different dates, they will tend to group together in the "Chronological Ordered" views as well.0
This discussion has been closed.