Problem - People merging duplicates merge the older PID# into the newer PID# and break everything.
Comments
-
Adrian Bruce said: #2 - survivor on the *right*
Since I only use the browser interface to FSFT, from my viewpoint, the argument that flipping is necessary for consistency is plain wrong. And like Jeff says, if you flip to having the survivor on the right, I will also screw up.
Intuitively, if you are brought up with a language written from left to right, if there is only one column (the survivor), then I think that you imagine that it will be on the left, where the text starts. So the current layout (survivor on the left) is more intuitive. I suspect!0 -
Tom Huber said: Same here. Please do not flip the survivor to the right. The only way that would work without causing massive confusion is the put the surviving profile in a special frame labeled "Surviving Record".0
-
Jeff Wiseman said: They've sort of done that already with the note that "everything in this column will be deleted after the merge" which is probably better because it's identifying what is about to be destroyed.
Also note that the data flow is shown as "Arrows" pointing from right to left instead of left to right.0 -
joe martel said: I'm starting a new thread regarding the polarity of Merge and considerations of what side the surviving PID should be on. Sorry to hijack this thread.
https://getsatisfaction.com/familysearch/topics/flipping-the-merge-survivor-side?rfm=10 -
Ross said: This topic's problem statement is really a combined expression of a problem and an asserted cause. The problem statement is that when people do a merge they sometimes "break everything". The asserted cause of the problem is that sometimes people "merge the older PID# into the newer PID#".
I don't doubt that merging older PIDs into newer PIDs often leads to problems but I do not believe that PID order is the root cause of the basic problem. I have run into MANY older PIDs created by "FamilySearch" that have NO attached source references to support the claims about the person represented by the PID. I typically delete those PIDs on a merge in favor of PIDs that have supporting sources. In other words, it is not the age of the PID that matters but the quality of the information supporting the claims associated with the PID. Also, many old PIDs have been corrupted by merges of PIDs that are not representative of the same person. (Untangling those messes is very time consuming which is leading me to make another suggestion which i will post separately.)0 -
Alexis Hok said: I'd prefer if you quote from the thesis statement in the first line paragraph. The long sentence at the top you quoted is really just the title.
The responses here have been overall surprising.
I hope enough comments have been posted though to support traction on this issue. I saw, Joe, where you were responding to people 3 YEARS ago on this same issue.
The only other major issue I had with FamilySearch before was people stealing PIDs from other trees to use as their own relative because they didn't understand how to create a new person and they expected to find their relatives names already in the system with the old layout. I think that issue was reduced by the new search window prompts, so I hope something will be done for this other issue.0 -
Ross said: I think you are talking to me in your first sentence. Alas, I agree.0
-
Alexis Hok said: Orphaned PID# 9VM7-H83
Not my relative, was searching for someone same name when I came across this.
His wife got merged and this spouse orphaned I think?
Just an example I am posting per request of examples and showing it is not just my own relatives.0 -
Tom Huber said: Not mine, either.
I think this was a conscious decision -- to orphan the William Neal record. The merges took place in 2014, four years ago. Whomever did the merges may not have realized that the ee sound with a southern accent sometimes comes out as a long "a" sound as in "ale".
The wife was merged and that surviving record was merged into yet another, whose husband was William Henry Nail. Given the time frame, names were often recorded how they sounded, and the people did not have a high literacy rate in the 1850s, so did not necessarily know the original spelling of the name.
The records came over from newFamilySearch, which had no change log. I don't know when reason statements were widely established, but for a while, they were not offered for every event and fact on a person's record.
After looking through the various records, someone will need to restore the two merge deleted records of Martha Etta Odom (the wife) to see what the full record looked like. I would not be surprised that the orphan husband and current husband are the same person, but because I am not related, I will not touch the record.0 -
Ala Härmä said: I have noticed that it is impossible to see during merge if a marriage has sources attached.0
-
Ross said: Christina, There are some circumstances that just beg users to do inappropriate merging. A Person that is representative of multiple people may be the worst case. When a Person has become a mixture of relationships, attributes, and sources of several people, like you mentioned, it will only get worse UNLESS someone does what you did to get the unique Persons separated. It would be nice if people would refrain from merging if they suspect EITHER of the Persons being merged are representative of more than one individual. A user considering a merge should (I think) fix such Persons before merging them. Unfortunately, I cannot think of a simple, sure-fire way of encouraging users to do that.
All that being said, I still think it is best to preserve ALL the relationships when a merge is done. Otherwise you will need to chase down all of the deleted Persons to extract sources, attributes, and relationships for the individual Persons that need to be created. That effort isn't any easier, and may be harder, than teasing them apart from one Person.0 -
Ben Strubl said: I come across same problem more than I care to remember and so time consuming away from the original family being researched to separate.0
-
Alexis Hok said: I wanted to thank the responders here for a tip they provided.
It gets very discouraging to find others 'merging' old PIDs into new PIDs and dropping the details in the 'Other Information' field, such as custom events and residences added.
Particularly for people pre-1850, I try to post details and notes from Wills, documents, military records and pensions that mention family relationships and locations to help properly identify a family. I include the details in the Life Sketch and 'Other Information' fields.
However, the 'other information' field is a field a person must choose to carry over during a merge, and people do not.
There is one lady in particular that creates new pages for my ancestors. I don't know if she wants to be the sole contributor on a blank page, or if there was one detail on a page she didn't like, but it gets frustrating to see all the work lost.
With the new setup, sources and notes get hidden in their own little category, so the page can look very blank when someone merges.
Today I realized two relatives had a lot of information lost due to a merge. I was disheartened when I thought of how much careful copying/typing I'd have to do to repost everything, when I remembered a tip someone said about 'restoring' a person.
I'd only done this on incorrect merges, but it worked beautifully for what I needed today (and saved on duplicating ordinance work). Thank you very much.
Restored PIDs and families fixed.
PID# 2M24-PXW
PID# 2M24-PJZ0 -
David Newton said: I'm not sure I'd call those families "fixed" at all.
With the wife I deleted a spurious duplicate name, standardised two place names, detached a useless NFS import "source" and edited a custom event to remove the year from its title field.
With the husband I standardised three place names (including one "event" which allegedly took place in 1772 in the "United States", yeah right), deleted a spurious duplicate name and edited several custom events to remove years from their titles.
That leaves a number of custom events that really belong in the sources section (deeds, wills, obituaries); the husband apparently having three parents and one of the sons allegedly being born in Meriwether County, Georgia in 1805 when that county wasn't even formed until 1827!! Shall I go on?
That section of FSFT needs an awful lot of work to bring it up to scratch. I suspect that quite a few people have made unwarranted leaps and bounds and just slapped it together over many years of so-called research. The lack of historical knowledge displayed by the husband being born in the "United States" in 1772 is appalling. Until I corrected that today it had gone unchanged for over 6 years, through dozens of edits to the profile, presumably mainly made by Americans. Far more sources need to be cited to back things up and a lot of those sources need to be uploaded to the memories section.0 -
Alexis Hok said: I think the issues with the work I've detailed on those pages aren't serious issues, and you may want to consider relaxing your edits.
Regarding place names:
I believe it is common for people to use a modern name for a location rather than its historical name (for instance pre-USA).
I deal with a lot of ghost towns, or towns that no longer exist that are not in current systems or maps.
I also have ancestors that indicated their birth place was a variety of names in records due to these issues. Why claim one is place is more accurate than another?
The ideal here would be to indicate both, but it is far easier for someone to use a modern name to find a location on a map (especially now that familysearch offers the nice google map feature).
What I'm trying to say is someone may want to add details into their own genealogy programs now and in the future, and using a modern name for a place is easier for them.
Regarding a year in a title:
Systems change, and my adding the year in the title of custom events is a relic to how things were organized in the past.
Organization on the person page may change again, and the method I used in the past may once again be helpful. To edit someone else's work due to a year in the title is a little..nitpicking maybe?
Understanding these little adjustments may help others with the way information is handled now and in the future.
For instance, it is proper in the written language to add a period after abbreviations. Like Mary A. B. Smith. However, due to coding limitations in the past, a name would get cut off after a period (like "Mary A Smith" or just "Mary A" .
Maybe this was due to the multilingual status in the past or whatever (languages without periods?), I'm no coder, but please notice this example and why nitpicking over a detail is unnecessary as we deal multilingual, computer coded systems that update and change.
Sorry to make a long post, hopefully I explained clearly as it was just a quick reply.0 -
Alexis Hok said: P.S.
Please do not remove my custom events. My family member (age 70) is often on a computer but it is not intuitive to her. She never adds sources in the source area as she doesn't feel confident adding them (she doesn't know what she is doing).
She can barely see where sources are now, since they have been moved under a little tab. She never clicks this little tab. Although I point it out to her, it doesn't help. She always asks for help to view the media tab too. I'm sure there are others out there that have the same issues.
My custom events help her. Maybe they help someone else. They certainly help me. Please do not remove them, thanks.0 -
David Newton said: Custom events have a date field. That is where any date belongs, not in the title of the event. As for place names you very much have it backwards. The standard is to name places as they were at the time the event occurred. The reason for that is to avoid precisely the problem that I highlighted about the son being born in 1805 in a county that did not exist until over 20 years later. Having the modern name provides significant obstacles to finding records: people going to completely the wrong county archives because the name is the modern county instead of the correct county for example.0
-
Ross said: Some of the latest (off topic?) commentary, suggests to me that enforced guidelines are sorely needed. The FamilySearch tree is a public, collaborative effort. As such, without an enforced consistency, it will likely be frustrating for almost everyone as conflicts in style arise and cause confusion. Without enforced consistency, the most persistent assertive personality will win out in different areas of the tree.0
-
Alexis Hok said: I respectfully disagree sir. There are just too many cases where the modern name can be more helpful than misleading.
For example: John Doe born and living in "Indian Territory." If I only posted "Indian Territory," how would following your advice lead me to the correct county? If I provided a modern name, how would that not narrow the field?
Some counties went bankrupt and merged with neighboring counties. To suggest those residents can not use the new county name is incorrect.
Some cities fall in two counties.
Many counties have divided and been renamed several times. Take South Carolina for example. They started with parishes, then had counties, then had districts, then had counties again, and the shapes and borders of these counties changed. Finding the right county archive may already be a struggle. I would still record a modern name if I knew the exact location, or the specific area.
I believe knowing a modern location helps narrow the search. For example, I deal with people born in countries that no longer exist. When I research records, I look under at least 3 different languages. Telling me I can only record one old location name does not help me find the modern county records.
How does my using a modern name in that example send people to the wrong county archives?
Have faith in your fellow researchers. Old records may already be difficult to locate due to all the historical changes. I use my judgement when deciding between an old name version and a modern version, rather than denying the use of any modern names.0 -
Paul said: Alexis
You make very reasonable points, but this is not how you should be recording events in Family Tree. This is shown by the fact that, when you are inputting a place name, the program now specifies which alternative place you should record. For example, for the places in England I want to input it shows the specific place name format to be entered according to the period in which the event took place and/or whether I am referring to a town/village or a registration district.
Yes, I have occasionally entered my own choice of place name if I have not agreed with the FamilySearch options. However, doing this is generally not in line with the collaborative nature of Family Tree, where we should generally be working in conformity.0 -
Alexis Hok said: These are good points. Although there is conformity, we need to practice judgement on what works best in the system, and not be so particular when others contribute.
Here is a recent example.
In the USA, a person's military rank first goes in front of the name.
Example: Lieutenant John Doe, or LT John Doe.
A cousin recently changed LT John Doe to John Doe, LT. I do not stress this. The information is there. Its a collaborative effort. If I stressed that cousin adjusting the military rank placement (this is a true story) I would be editing every person year after year to fix any issue.
Here's another example.
John Doe was born in location X. A year after his birth, location X is renamed to location Y. During his lifetime, John Doe always reports his birth location as Y.
Yet, by standard, you would have me change this man's birth place to the old location X. This actually causes issues for anyone looking up his military records and such. (There was no birth certificate during this time.)
How I handle this may be different from you. When I record the birth location, I used location Y. This was helpful while I researched the person and I noted the name change where I could.
Someone a year later changed the place to old location X. I do not stress it. The information is there and documented. It's only stressful when people delete all the research and merge to a blank new PID# with no family connections!
As Paul mentioned, there can be issues with the location name not in the system.
FamilySearch doesn't have every ghost town. Using a standard format helps others to 'find' the person in the system (to prevent people making duplicates). Sometimes I'll use an old town name or district, but if it is too obscure, people might not make the connection and make their own duplicates without connecting our trees.
There will always be exceptions needing judgement calls.0 -
Paul said: Just a thought on burial locations and use of the appropriate place name. When I initially viewed an input by a user showing someone buried in the 19th century, but in an English (metropolitan) county that did not exist until the 1960s, my immediate thought was to change the standardised name to what it would have been known as back then. However, perhaps it is better to leave it as it is, as it might help somebody find this relative's grave more easily if the currently named location is shown.
Alexis has a point about flexibility (and commonsense) needing to be applied in this matter, particularly if not sticking firmly to "correct practice" might be of far greater help in finding a relative - literally, in the case of a deceased person's remains!0 -
Ben Strubl said: Traditionally Military rank is a title and comes before a name. Where Doctors such Dr, be placed in title or MD as suffix, Atte or Atty for Lawyers in title or Esq. in suffix.0
-
Adrian Bruce said: I think the problem of finding a grave has come up before and it's an important and interesting one.
For instance, as a result of local government reorganisations, someone could be buried in "Birmingham, Warwickshire, England" but their grave today would be in "Birmingham, West Midlands, England". Now personally, I'd just record a burial event in "Birmingham, Warwickshire, England", but if the alteration of the place-name were more drastic (e.g. from a German name to a Polish), then one option would be to still record (keeping to my example) a burial event in "Birmingham, Warwickshire, England" but add a custom attribute of "Grave Location" with a place of "Birmingham, West Midlands, England". This may sound unduly pedantic, but pedantry does often have its uses in separating out two different concepts.
Of course, another method could be to actually use the map facility!0 -
Adrian Bruce said: Ben - I agree with you - this is another illustration of the need for a Wiki style Style Guide. For instance, I get confused over the mainland European usage of "Ing." and similar as a prefix for formally qualified engineers, whereas the equivalent in the UK would have been a post-nominal suffix.
(This is why at least part of it needs to be a Wiki style Style Guide - it would be absurd to expect such localised, specialised knowledge to be a/v in Salt Lake City.)0 -
Adrian Bruce said: "John Doe was born in location X. A year after his birth, location X is renamed to location Y. During his lifetime, John Doe always reports his birth location as Y.
"Yet, by standard, you would have me change this man's birth place to the old location X. This actually causes issues for anyone looking up his military records and such. "
Alexis - this is actually a good example of an issue. I don't have a good solution because several things clash.
My personal viewpoint is that one should always use the contemporary place-name. Except when one shouldn't... :-)
I think it important to start with the viewpoint that genealogical best practice is to use the contemporary place-name (X here). To start by saying that Y is the best because .... (which isn't what you're doing) is rather like introducing speed limits in a driving course by first saying when they should be broken - it's not good psychology.
Really and ideally, what needs to happen is that X and Y should act as synonyms - if I enter X as the birth-place, and trigger a search of military records, then ideally it should bring up the record with Y. I am, however, not at all sure if search routines in FamilySearch can do that.
In truth, because of that, I'd be very tempted to enter Y in the Birth in Vital Events in your case. In fact, I think I remember reading somewhere here where someone (of experience) had carefully entered the correct "Utah Territory" as a place-name, only to discover that the FS searching failed dismally for those people - to her disgust, she had to revert to "Utah". It's important to note that this isn't a failure of Genealogical Best Practice - it's a failure of Genealogical Search Algorithms.0 -
Juli said: Census instructions (for example) were to enter the then-current names of places, which is how all sorts of people are listed as being born in Czechoslovakia in years when no such country had ever been dreamed of. (It gets especially, um, entertaining when people couldn't quite remember what the place was called in the new administrative language, or didn't know how to spell it.)
Ideally, the search algorithm should be able to turn up records under any name and jurisdiction that was ever correct for a location. This is certainly one of the goals of the Places team, but it is a distant dream in some areas. In the meantime, one simply has to be flexible. It also helps to record (as a Note or custom fact or something) the information one finds about the evolution of relevant placenames.0 -
Adrian Bruce said: It must be even more "interesting" / "entertaining" when the then-current birthplace covers several contemporary countries. For instance, if the 1900 census says someone was born in "Germany" in 1850 - where would that be? Because "Germany" didn't exist in 1850.... What does one put then?
(Don't get me started on what the standard place-names have for pre-1871 "Germany"...)0 -
Ben Strubl said: True Adrian pre-1871 Germany was the Germanies a loose knit group of Duchies with no set alliance to a Central ruler. Electors who ran their Duchy later adopted Nobility Titles, they often in times of war would align with a German King, Austrian Emperor, or sometimes a French King.0
-
this thread began about the → Lack of in-depth Instruction on how to process merges without loss of data & relationships (or lack of the system in preventing loss through aiding/guiding users). I can't find instructions on this issue.. if they exist, I would be grateful if a link were provided. (full disclosure: I too have inadvertently caused myself problems through merging.)
SPECIFICALLY: need detailed IF • THEN • ELSE scenarios that address big picture strategies ..
example: in a case where 1 member has 3-4 duplicates PLUS his/her PARENTS and GRANDPARENTS all have duplicates as well. Should one .. start from the bottom and work up the generations or start at the generation that is the oldest and work forward in time.. or does it not matter? Should I create a new person [when required] first or force it by way of merging?....
Lacking process instructions - or my ability to find them if they exist, on the topic of How to Prevent Loss and Multiplicities, results in hours of work FIXING the issues created by the merge.. in the end most merges create more problems than they solve. At least half the dups I find began with the system adding multiple entries for the same person along with family members, often on the same day or in the
same week. April 12-14, 2012 comes to mind.
As well, I find the system does NOT alert you to clear and present duplicates -- perhaps if the algorithm could be made more robust on the front end, headaches could be avoided. ♥
________________________________________________________
I found these instructions on this site:
1 https://www.thefhguide.com/blog/the-basic-steps-in-cleaning-up-the-familysearch-family-tree/
Here are the steps that we need to go through to clean up the Family Tree:
1. Carefully review every entry currently in the Family Tree for completeness and accuracy. Review every source attached and read and/or review every attached memory. This is not an optional exercise. If you haven’t read and reviewed every source and memory for each individual you work with, you have no business changing or adding information to individuals in the Family Tree. Don’t cause more errors and confusion by ignoring this requirement. If you ignore the sources and memories, you are just making more work for those of us who did the original research.
2. Standardize all dates and verify and standardize all locations (i.e. places). Make sure that the place listed for each event in every entry is consistent with the reality of the time period involved. Always look up any places you are not familiar with a look at where they are on a map such as Google Maps. Especially look for consistency in where children listed in the families were born. Remember the First Rule of Genealogy: When the baby was born, the mother was there.
3. Start researching every entry (every single person) by adding any appropriate Record Hints. Do not add record hints that are inapplicable or incorrect. Think about what you are doing. Does it make sense? If you don’t have research skills, start by learning before you simply increase the errors and duplicates already in the Family Tree.
4. Continue doing more research until each entry is supported by multiple historical records including source citations to those records. Any entry with no sources should be considered inaccurate or wrong until supported by a historical source. If an individual in the Family Tre has only one source, remember that only the information in that one source is verified. For example, a birth or christening record does not validate a marriage.
5. Be sure to copy all information from the historical records into the entries for each person.
6. Resolve any potential duplicates including using the feature to look for similar names.
7. Standardize the dates and places over and over as new sources are added.
If you do not know enough to perform all of these steps, take the time to learn about how to do any of these steps before doing anything. In my opinion, learning how to do genealogy right is counted as more important than simply doing something especially if what is done is wrong.
As I write this, I have just spent a considerable amount of time correcting entries with no sources listed, no complete names, dates that were somehow imagined to be correct, and no connections to anyone else in the Family Tree. I hope my frustration came through in this post.
If you don’t know how to do anything I have mentioned in this post, start here:
0
This discussion has been closed.