My question is about duplicate sources.
- My ancestor, who died in 1952, had duplicate sources added by the same or different people. When a duplicate is added doesn't the system show that it has already been attached? When I deleted the duplicates so that only one source for that purpose was posted, the system added them all back to my hint listing for that person. Why does the system do the above?
- My 2nd question is why do we post sources to multiple people? When a child is born, we don't have to post every event to both parents, just post to the child and make sure they are attached to the correct parents. I struggle with parents that have 13 children and 60 or 70 sources, when I try to add sources or eliminate duplicates. Could the sources be sorted with the personal sources at the top and the secondary sources all at the bottom.
Thanks
Ross Farrer
Best Answers
-
I have a different perspective.
There are many records that have been indexed multiple times. If we don't attach all 5 indexes for Joseph's baptism, we run the risk of having 4 duplicate Josephs created. I personally try to attach all versions of a source to try to prevent the proliferation of duplicates.
In many cases, in my research, there are already 5 Josephs, each with one source attached. When we merge all those Josephs and his parents, then there are 5 baptisms attached to him and his parents.
An example - my GG Aunt Mary Hughes. There are 4 records for her baptism attached to her and my 2nd great grandparents, Patrick and Mary. https://www.familysearch.org/tree/person/sources/9JDK-2RY It took me a LONG time and a lot of work to sort out all the duplicates and triplicates of Mary and her 10 siblings. If those sources were detached from her profile, I would run the risk of having to do that work all over again.
1 -
On your first point, it can be a good thing when there has been multiple indexing of the same record. For example, the project instructions might vary for two different indexing projects involving the same material and they each might contain slightly different detail that complement each other. However, I agree that the downside of multiple indexing is the clutter that is often caused - especially annoying if the indexed records are identical!
On your second point, I have been unable to persuade anyone that it is not really that necessary to add all those sources that are for events that relate primarily to a child or spouse. Again, so much clutter in cases where someone had about ten children, each of which have baptisms that have been subject to several indexing projects! I prefer to move all these events to the bottom of the person's sources section, in order to keep their own Vitals details to the top. Others prefer to keep everything in strict chronological order, however. Either way, sorting the order of 60+ sources for each member of a family can be quite exasperating.
In summary, I now just go along with the instructions, and the way that the majority of Family Tree users seem to find quite acceptable. As Family Tree is a collaborative effort, it's probably best we all try to work as closely as possible in our methods of adding data, regardless of our personal preferences and/or what we would consider to be more sensible or practical.
0 -
Part of the answer to the "why" in your question(s) is that there can be multiple records of an event, multiple filmings of those records, and multiple indexes of those films.
For example, many church rites (baptisms, marriages, burials) were recorded in both a parish register and a bishop's or archive copy of that register. Either or both of these records could have been transcribed or indexed later (often on a typewriter in the early 20th century). Then, in the mid-20th century, microfilming came along; any or all of the existing records of an event -- parish register, bishop's copy, later transcript/index of parish register, later transcript/index of bishop's copy -- could have been filmed. Sometimes, a page was filmed twice, for example if the technician felt there was something wrong with the first image. Sometimes, entire registers were re-filmed. (Purposely or by accident -- it hardly matters, to us.)
Then along came computers. Any or all of the records, in any of the forms they existed in, could be subject to computer data entry, although generally the older databases on FamilySearch are based on microfilm, not on paper or parchment. (Newer databases are based on digital images, either of microfilm, or directly of paper or parchment.) If a page or register was filmed twice, it was almost always entered twice, because it wasn't generally the same volunteer indexer who got assigned both copies. For some records, the many-decades-old original computer index is what is still in use today (such as some parts of the IGI), but some records have been re-indexed by some entity or other. Sometimes, FamilySearch has copies of multiple indexes of the same version of the same records -- and no, those indexes don't always agree.
And then there are the more individualized causes of duplication, such as indexing errors that turn a multiple-named person into twins or triplets. Sometimes, it's not the fact that there are three versions of the same event that's surprising, it's the fact that there are only three versions.
But yes, in the current data structure and presentation of FamilySearch, you really do need to attach all of those different versions of the same event to all of the people who are indexed as participating in that event. Otherwise, some helpful soul will eventually come along and create a mess of duplicates and/or incorrect associations.
One tool for managing the proliferation of source citations is to edit their titles. The auto-generated titles are often identical and therefore useless, but you can individualize them, and on a patriarch with twelve children and a hundred sources, you could even come up with a numbering system. (You can either use a custom sort to maintain the numbering, or you can hijack the sort-by date field for the purpose.)
2
Answers
-
One post has been edited to remove personally identifiable information.
1