Gedcom Challenge: Show Us The Data
Comments
-
rotkapchen said: Communication is part of the problem and no, repeated pleas are of no consequence and even when they are, the person has no tools by which to fix the problem they created.
THIS has been repeatedly ignored.0 -
rotkapchen said: The madness continues, unabated, unresolved and mostly denied.
Never mind the fact that I'm reporting issues with loads by individuals that are still being ignored as a problem (e.g. Wilfred G. LeBlanc) and no tools being administered by which to fix the damage. I will conjecture that if such tools were created we would find all SORTS of duplicates that are being denied as even existing.
1/5/2020
So much for duplicate GEDCOMS not being allowed: 2 January 2020 by JCaron
https://www.familysearch.org/tree/mer... GEDCOM Dup by JCaron
https://www.familysearch.org/tree/mer... GEDCOM Dup by JCaron
https://www.familysearch.org/tree/mer... GEDCOM Dup by JCaron
https://www.familysearch.org/tree/mer... dup by TerryMcElroy, wrong surname
https://www.familysearch.org/tree/mer... GEDCOM dup by EnesWFick1, B/C/I/E completed
https://www.familysearch.org/tree/mer... old GEDCOM dup
https://www.familysearch.org/tree/mer... old GEDCOM dup
https://www.familysearch.org/tree/mer... old GEDCOM dup
https://www.familysearch.org/tree/mer... old GEDCOM dup, released to temple for duplicate work, B/C/I completed
https://www.familysearch.org/tree/mer... old GEDCOM dup
https://www.familysearch.org/tree/mer... old GEDCOM dup, released to temple for duplicate work
https://www.familysearch.org/tree/mer... dup by TerryMcElroy, bad birth
https://www.familysearch.org/tree/mer... dup by TerryMcElroy
https://www.familysearch.org/tree/mer... GEDCOM dup Karen Sue StriblingShowell
https://www.familysearch.org/tree/mer... new dup by FrancineBelanger1
https://www.familysearch.org/tree/mer... GEDCOM dup by Wilfred G. LeBlanc
https://www.familysearch.org/tree/mer... GEDCOM dup by Wilfred G. LeBlanc
https://www.familysearch.org/tree/mer... GEDCOM dup by Serge Villeneuve, printed B/C duplicated
1/6/20
https://www.familysearch.org/tree/mer... GEDCOM dup by jpbmass, full of errors, printed for work B/C comple… [truncated]0 -
joe martel said: I looked at a few of those URLs. Some are this year, some older. I don't know this line well and some of the Merges weren't obvious to me to merge.
I have to say that this is a lot of work and I'm sorry that some users are either not paying attention, or not familiar enough with the family, or that the software to compare isn't better. I also believe more and more that some lines are very susceptible to duplicates because of relative users that have been involved. There have been many discussion about how to reduce duplicates (and many more come from products other than Gedcom) and the ideas are by no means simple, nor making much traction.
I am curious though. Have you reached out to these other users and gotten a feel for where they are getting their data from and why they are using the mechanism they do, and if they even notice the dups?0 -
rotkapchen said: I always reach out to the loaders. I almost never hear back from them. One admitted she loaded from Ancestry. As I've outlined before another individual wanted to fix her load but we could not determine a means to do so.
Please do not tell me how difficult this all is when at the very least a utility to unload or to review and correct the load could be provided and never had been (a HUGE oversight in the original design that is unacceptable). This utility should not only be available to the loader but to others as well.0 -
rotkapchen said: For those not obvious to merge, this would suggest why the merge logic could be flawed. I studied the data. All merges were based on the data.0
-
MAC said: One question -- if a user uploads a GEDCOM after they have already uploaded another one, does FamilySearch compare the GEDCOMs themselves to see if there are duplicate individuals between the two (and not just do the compare against Family Tree itself)? I just saw one user today who has created the same person 5 times. I think she is just uploading her GEDCOM repeatedly, and since for this particular record she's uploading just a (common) name and years of birth/death, the algorithm doesn't have enough information to match.
I think it may be helpful to do a quick comparison, so that FamilySearch can flag to the person that, say, the GEDCOMs are x% similar, and that re-uploading it would introduce duplication (and possibly include a link explaining why duplication is bad).0 -
Jeff Wiseman said: I believe that the answer to your question is no. Also, although some of this duplication may be getting done in ignorance, I suspect that people have discovered how to get around the "limitations" of a shared tree in order to load their own data into the database and keep it separate with little or no work. Skim over some of the comments I have made above in this thread.0
-
rotkapchen said: No new GEDCOMs? New load February 28th. Again, it would be nice to be able to trace the entire load to find the errors and correct them -- backing into them takes years!!!!
2/28/20
https://www.familysearch.org/tree/mer... GEDCOM dup by Melanie Dunne, B/C duplicated Feb 28 GEDCOM load Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin
3/8/20
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, duplicate sealing printed
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, reserved for work, bad data spouse added
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, reserved for work, bad data
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, reserved for work
https://www.familysearch.org/tree/mer... dup by HelpFH what is this? (also noted as "your friend or relative"), duplicate sealing printed
https://www.familysearch.org/tree/mer... dup by HelpFH what is this? (also noted as "your friend or relative")
https://www.familysearch.org/tree/mer... dup by HelpFH what is this? (also noted as "your friend or relative")
https://www.familysearch.org/tree/mer... GEDCOM dup by Raymond Kerr, all ordinances duplicated
https://www.familysearch.org/tree/mer... dup by HelpFH what is this? (also noted as "your friend or relative"), B/C already completed
https://www.familysearch.org/tree/mer... dup by AdamsShepardAlfred1, B/C/I completed0 -
rotkapchen said: [Trying to work around the login issues in Chrome right now -- have moved to Explorer as a workaround]
I have a large number of more duplicates by Louise A. Martin, many of which have been released to the temple already and many of which have already had B/C/I completed.
The darned thing is, nearly every one of her entries has basic data commentary added (in Other Information) detailing ordinance work, say Baptism and Confirmation all for dates in 2018 -- all of which themselves are duplicates. So effectively, she's loading data for all of the duplicate temple work she had done for records that then are being picked up and being done AGAIN!!!
And yet no one can provide me an exception report that I can manually find and assess each of these adds to determine if they are duplicates and fix them. If you can't FIX the problem, at least provide a workaround that I can manually do this more intelligently.
What say you Official Rep?0 -
rotkapchen said: 3/16/20
https://www.familysearch.org/tree/mer... GEDCOM dup by ChristieLents (loaded 2/15/2020)
https://www.familysearch.org/tree/mer...
https://www.familysearch.org/tree/mer... dup, sealing printed
https://www.familysearch.org/tree/mer... GEDCOM dup by Kyle Blake_1, reserved not printed
https://www.familysearch.org/tree/mer...
https://www.familysearch.org/tree/mer... GEDCOM dup by thomasedwardflanagan1
3/20/2020
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, bad data, birth of sister
https://www.familysearch.org/tree/mer... GEDCOM dup by AdamsShepardAlfred1, reserved for work
https://www.familysearch.org/tree/mer... GEDCOM dup by MarilynTreuil1, B/C/I already duplicated
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, B/C duplicated, released to temple for work
https://www.familysearch.org/tree/mer... Same GEDCOM entries by Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, bad data
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, released to temple for work
3/23/2020
https://www.familysearch.org/tree/mer... GEDCOM dup by michelew8019, B/C/I already duplicated
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, bad data, released to temple for work
https://www.familysearch.org/tree/mer... GEDCOM dup by GeorgeThibodeau, bad data, released to temple, B/C/I completed
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, released to temple for work
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, bad data, printed, B/C completed
0 -
joe martel said: PID's are your best way to show the problem.0
-
Jeff Wiseman said: Hey Joe,
Respectfully, ALL of the links that rotkapchen has provided over the last 7 months have all contained those PIDs. In fact they have gone even farther and provided BOTH of the PIDs for the duplicate pair of persons, as well as hot links to both of those PIDs (i.e., both the PID deleted via the merge as well as the PID that survived the merge).
I suspect that if rotkapchen were to provide the redundant PIDs in addition to the information and associated links already provided, it would only be additional work and would just congest the already detailed lists that have so exhaustively been provided. I fail to see how this extra work at this point would add any value, even for someone trying to actually solve the problem.
In fact, rotkapchen's plate is more than full with work needed to correct and keep up with these people who are exponentially creating more work through abusing the data in the tree and ignoring rules necessary for a shared tree to exist (whether ignorantly or otherwise).
It appears obvious to me what is happening here. People have their own personal "tree" stored in a non-FS account somewhere (e.g., Ancestry.com). Then, in order to get the temple work done, they keep dumping the same GEDCOM data (each time with a few tweaks) into the FamilyTree as a separate tree mainly detached from everything else in the FSFT world. They have no interest in "blending" in their tree data during the GEDCOM data transfer, or merging into what already exists, because it is THEIR data (which is "obviously" the only correct data). From that point they either reserve the duplicates for themselves or Ordinances Ready jumps on them and assigned them to somebody.
Like rotkapchen, I have also found that a lot of the people doing this have no interest in changing their workflow to something more correct. Also they frequently have no interest in discussing the fact that what they have recorded is incorrect when you look at a couple of sources that are available. The ONLY solution here is intervention by FS (which they apparently don't want to do)
Unfortunately, these are the facts, and rotkapchen has provided a massive preponderance of data showing this abuse in the system. And yet after several years of GEDCOM discussions showing nothing but the problems that have come from those features, I continue to be amazed that the ONLY positive side of the argument that has been provided (i.e., so a person doesn't have to type everything from their personal records into the tree) continues to be upheld as far more important than mitigating the abuse in the tree and the destruction of well researched data.0 -
Brett said: All
As I have suggested previously ...
The REASON there will be NO Action to STOP the "Up-Load" of GEDCOM Files into "Family Tree" of "FamilySearch" is simple; and, has been proffered in this Forum before ...
PARTICIPATION ...
QUANTITY over QUALITY ...
Or, in another way, "Participation" over "Substance" ...
The problem/issue is that the general populous WANT their, DATA; and, their (Temple) WORK to prevail, no matter what ...
Unfortunately, that is 'human nature' ...
We ALL think WE know all; and, WE are the ONLY "One" that does ...
Hence, the amount of (Temple) WORK being done for "Duplicates", that were "Dismissed" as "Duplicates"; and, NOT, "Merged"/"Combined".
That 'all boils down to' ... TRAINING, Training; and, more, training ... by the "Stake/Ward/Branch, Temple and Family History, Consultants".
There is much less trouble from the non-member Users/Patrons, than from the Member Users/Patrons.
The non-member Users/Patrons ARE better "Genealogists" (ie. Genealogy/Family History Researchers), than the Member Users/Patrons.
I know, 'been there, done that', still do ...
==========
FamilySearch
PLEASE ...
Immediately ...
STOP the ability to load GEDCOM Files into "Family Tree" of "FamilySearch".
There is ALREADY the ability to load GEDCOM Files into "Genealogies" part of "FamilySearch" - just leave it at that, that is all that is needed ...
Even if the (individual) "Branches" of a (new) User/Patron, of this massive, interconnected, SINGLE "One" World "Tree", for all of us, that is "Family Tree" of "FamilySearch" 'Tree", are NOT there, have them add individuals/person on a 'one by one' basis - they (the new Users/Patrons) will at least learn how "Family Tree" of "FamilySearch" works.
And, that will, at least, slow down the ability for those that want their, data; and, their (Temple) Work to prevail, no matter what ...
And, there is still the ability to load through the 'Third Party' Programmes that are "Certified" to work with "Family Tree" of "FamilySearch".
'Thank You' in advance.
==========
Brett
.0 -
m said: Well said by Jeff and Brett.0
-
joe martel said: Thank you for the info. The difficult part is finding time to investigate all these. I know Gedcom import and many other products inject duplicates and mess up data so the research involves many different products to investigate.
When I have a few moments I spot check a couple. I always go back to the date where the problem occurred, this alone takes time for me to scan changelogs of one or both affected PIDs. This takes time. If the mess up happened more than a month ago the internal data is no longer available. So I focus on the things that happened in the last month. To me that's an indication of an ongoing, current issue that might be able to be addressed.
When it comes to user behavior it becomes more tricky. We are all at the mercy of our own and other user's work practice. Those products are all subject to their users' behavior. So we see bad players in many of the products. The ones where bulk uploads are easier, like Gedcom and other partner products, can affect data much more quickly.
Many users, even those posting on GetSat, request easier ways to do this or that, or to reduce the repetition to accomplish tasks... and these productivity goals requested are often at odds with quality goals. Striving for the balance is a never-ending battle. Controlling users is tough. Who is right? Who polices?
Shutting off Gedcom ingest and partner added persons functionality is unlikely to happen. I wish there were better processes for ingesting added persons and I wish we could better train these uploaders that don't understand the damage they do. Unfortunately a number of users are the popular targets of errant uploads, because their trees overlap into the uploaders tree, and this happens repetitively.
There are approaches to gate these errant uploads, but the design is complicated and are simply guesses as to whether it would help. I wish I had better news, that there was more attention to this. Though aware, a clear, executable path is still not defined. My only advice is to reach out to those fellow users that are most likley unaware and help them in a kind way to understand.
It's a long shot. I want to help more. If you provide some targeted PIDs over the last 30 days coming from a specific user perhaps a list could be made available to you. But I don't decide what happens, what gets coded, ...0 -
Brett said: Joe
Your 'participation' and 'candor' in this Forum is always ... much appreciated.
But ...
That said ...
It is certainly possible to STOP the "Up-Load" of GEDCOM Files into "Family Tree" of "FamilySearch"; as, there are FREE "Partner" Programmes that can be used to "Add" individuals/person in "Family Tree" of "FamilySearch".
As such, I would humbly, suggest that, there is NO "Reasonable" REASON for "FamilySearch" to continue to allow the "Up-Load" of (Raw) GEDCOM Files into "Family Tree" of "FamilySearch".
Brett
.0 -
joe martel said: Correct me if I'm wrong, but Gedcom upload has the same one-at-a-time flow that other third parties do. Those same products may then do a bulk upload of those user-reviewed and accepted persons.
It may not be apparent to those users that those products upload in chunks at a later time. User's don't see the source product fingerprint because most those products don't show their involvement in the transaction.0 -
Brett said: Joe
I have never (and, will never), either, (1) "Up-Load" a GEDCOM File into "Family Tree" of "FamilySearch"; or, (2) use a 'Third-Party' "Partner" Programme, to "Add" individuals/persons in "Family Tree" of "FamilySearch".
And, to some degree, I do not care how such an upload is effected.
But, admittedly I would hope that such an upload would be on a 'one by one' basis, through a Very STRONG "Compare"; so that, the individual/person ALREADY in "Family Tree" of "FamilySearch" (regardless of the origin of that record) WAS the "Surviving" individual/person; and, NOT, the individual/person from, a GEDCOM File; OR, a 'Third-Party' "Partner" Programme.
All I know is that, there SEEMS to be MORE "Damage" done through the "Up-Load" a (Raw) GEDCOM File into "Family Tree" of "FamilySearch", rather than through an "Up-Load" through (or, otherwise - whatever they do) a 'Third-Party' "Partner" Programme.
Easy ...
Just STOP the "Up-Load" (Raw) GEDCOM Files into "Family Tree" of "FamilySearch"; and, ONLY allow "Up-Load" through (or, otherwise - whatever they do) 'Third-Party' "Partner" Programmes.
I do not know; but, I would hazard a guess that such would not stop; but, certainly 'curtail' much of the "Damage" to individuals/person in "Family Tree" of "FamilySearch".
Certainly not stop it; but, certainly 'curtail' it.
I just DO NOT understand the RELUCTANCE of the Management of "FamilySearch" to simply STOP the "Up-Load" (Raw) GEDCOM Files into "Family Tree" of "FamilySearch" - 'cold turkey'.
Just DO IT ... NOW.
There are MORE "Acceptable" ( FREE ) ALTERNATIVES, rather than the use of (Raw) GEDCOM Files.
Get over GEDCOM Files ...
Just my Thoughts.
Brett
.0 -
rotkapchen said: "Many users, even those posting on GetSat, request easier ways to do this or that, or to reduce the repetition to accomplish tasks... and these productivity goals requested are often at odds with quality goals. Striving for the balance is a never-ending battle. Controlling users is tough. Who is right? Who polices? "
Truer words have never been spoken:
1. This request is clearly NOT at odds with quality goals and should be prioritized above those that are not. Indeed, the biggest issue is that from everything I have seen for the past 12 years there is no quality policy and therein lies this dilemma.
2. Controlling users is only tough when mitigating designs have not been implemented. They are still sorely lacking and can be done -- I've done them myself.
3. Who polices? Surely not the support staff. But therein lies another core issue to this supposedly 'social' environment -- there is no option to police. Indeed, my 'begging' in this thread is to provide the means for dedicated individuals such as myself to mitigate some the flaws of the system (yes, the design). A core component of any data quality strategy is to have data stewardship. How that gets implemented can take many forms -- but in this environment there is none. Thus this conversation continues unabated.
And lastly, you have repeatedly failed (clearly intentionally) to address the request from the very beginning, months ago: why can't the actual count of ordinances be exposed for every record so we can see whether or not there is an issue? We simply keep hearing claims that this is NOT an issue.
I beg to differ and will keep doing so with evidence until my hands bleed.0 -
Stephanie Spencer Booth said: Point well made, rotkapchen.0
-
joe martel said: I am sorry if I have set some unrealistic expectation and have thus failed you.
I'm not sure there is anything else I can say to make my opinion less inflammatory.
If you find it necessary to know how many times an ordinance has been done then support is probably your only avenue, though I'm not sure they have access to such info.
I do desire to help you and my suggestion to provide targeted ID's still stands.
Otherwise, I will defer my comments.0 -
Stephanie Spencer Booth said: Initial support contacts do not have access to the ordinances. Your case would need to be transferred to a special support team. This team is already overwhelmed with requests to handle correcting incorrect merges done in new.familysearch.org. They can view all temple ordinances for a record and also transfer ordinances to the correct record. I don't think asking them to count repetitive ordinances for the same person is a good use of their time, but it would be illuminating to know how many times ordinances have been done for the same person.0
-
gasmodels said: I am not sure what you learn from knowing how many times an ordinance has been completed. Does it really help to know whether it has been completed once or it has been completed 6 time. It is really only of use when you know the dates and whether the duplication occurred before New FamilySearch was introduced. We know that there was a lot of duplication before and the purpose of nFS was to reduce that duplication.0
-
Stephanie Spencer Booth said: Often it's been completed 600 times, and not just before nFS or during nFS. Because of GEDCOM uploads, this is still happening in Family Tree on a massive scale.
I think rotkapchen would like for FamilySearch do some research on the PIDs she's posting and see that it's probably 600 times for each one. Then FS needs to recognize that GEDCOM uploads are a major stumbling block to completing temple work for individuals who actually need it.
Then FS needs to do something to stop it, because completing this task is more important than participation in the tree or ease of inserting incorrect data on the tree.0 -
rotkapchen said: Data people, data. The value of data is in the comparisons. Therein we find rates or speed. To suggest that there is not an issue and yet if in 2018 the ordinance count for one record is 35 and now it's 40 we have a rate at which the duplicate work is increasing. We can better define the problem that I am seeing first-hand, but do not have the data to tell the story.
This is not a matter of 'feelings' Joe -- it is a matter of results and in 12 years we've seen no progress on the issue of duplicates. Sadly, you are not the correct resource to be addressing this. Is there no escalation process? How are 'issues' prioritized in the grand scheme of things? I find it very difficult to believe that anything related to data quality that impacts sacred work is not somewhere at the top of the list.0 -
rotkapchen said: Not sure if it is just me locked out of the system just now, but in the meantime I want to capture the work of the past 2 days. Today was sidetracked by all sorts of merge unraveling issues and lots of research to correct bad data. I know there are a whole series of duplicates I haven't gotten back to.
Happy First Vision day...the work goes on, hopefully not backward.
3/25/2020
https://www.familysearch.org/tree/mer... GEDCOM dup by Wilfred G. LeBlanc, bad data missed match, B/C/I duplicated
https://www.familysearch.org/tree/mer... new duplicate by Reese AnneHudkins
https://www.familysearch.org/tree/mer... GEDCOM dup by Wilfred G. LeBlanc, bad data missed match, B/C duplicated
https://www.familysearch.org/tree/mer... GEDCOM dup by GeorgeThibodeau, bad data, B/C/I duplicated, released to temple
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin bad data
https://www.familysearch.org/tree/mer... random new record by Erin_Bergeron, reserved for temple work
https://www.familysearch.org/tree/mer... random new record by Erin_Bergeron, reserved for temple work
https://www.familysearch.org/tree/mer... random new record by Erin_Bergeron, reserved for temple work
https://www.familysearch.org/tree/mer... random new record by Erin_Bergeron, reserved for temple work https://www.familysearch.org/tree/mer... random new record by Erin_Bergeron, reserved for temple work
https://www.familysearch.org/tree/mer... dup by PeterSchuelke1, released to temple, B/C/I completed
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin
https://www.familysearch.org/tree/mer... GEDCOM dup by Louise A. Martin, bad data
https://www.familysearch.org/tree/mer... dup by AdamsShepardAlfred1, printed for temple work B/C/I completed
https://www.familysearch.org/tree/mer...… [truncated]0 -
David Newton said: Not just you: the authentication server appears to have gone boing in a fairly spectacular way.0
-
rotkapchen said: Thanks David.0
-
Don M Thomas said: I am almost to the point of Just dumping myself to get Temple work done, and forget about the so called FamilySearch "Family Tree." Too much sending out e-mails and in-house-messaging to get other patrons to see their mistake. Too much Warring!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0
-
ATP said: Yes! "Get over GEDCOM files!"0
This discussion has been closed.