Split a person into two people

LegacyUser

Abigail Mae Hardy said: Can we please have a split person function that is the opposite of merging persons? This would ideally have the original person in the middle of three columns with a way to swipe information to the two new people (on the left and right) to make two new separate people.

LegacyUser

Jordi Kloosterboer said: You can use the restore feature. If the person was not already merged, you can just create another person and apply the correct relationships and vitals. I had to do this today because someone had merged two families (but not with merging profiles, but with sources (so one person had 2 sources for 1881, 1891, and 1901....). It was quite a mess but I was able to sort it out.
Otherwise a splitting function would not seem like a good idea especially with the program knowing which way LDS ordinances went. That's just my take on it.

LegacyUser

Brett said: Abigail

Firstly, "Welcome" to this "FamilySearch" ( "GetStaisfaction" ) 'Feedback' Forum.

Secondly, "Official 'FamilySearch' Representatives", do monitor; and, sometimes, participate in, this Forum.

Thirdly, I am just another User/Patron, just like yourself (and, happen to be a Member of the Church).

Many Users/Patrons who regularly participate in this Forum who have a great deal of knowledge and experience with "FamilySearch", like to assist/help other Users/Patrons like yourself.

Finally, we already have the ability to, either, "Un-Merge"/"Un-Combine" individuals/persons; or, in some cases, "Restore" the "Deleted" (or better "Archived") individual/person.

We might think that we know how best to "Split" a "Merged"/Combined" individual/person; but, personally, I would rather have the respective individuals/persons that were "Merged"/"Combined" SIMPLY "Returned" to the closest state they were in BEFORE a "Merge"/"Combine".

It is not always possible to get the individuals/persons to "Return" to their EXACT state that they were BEFORE a "Merge"/"Combine", due to some/certain "Change" that have been made following a "Merge"/"Combine".

It is usual for the "Deleted" (or better "Archived") individual/person to be "Returned" to their EXACT state that they were BEFORE a "Merge"/"Combine"; but, certainly, not always the "Surviving" individual/person.

I prefer what we have now, rather than what you suggest; as, sometimes what we think that we know to be the best way to "Split" a "Merged"/Combined" individual/person is not always so.

I understand the premise of your suggestion; but, I like what we have now, I prefer to just, either, "Un-Merge"/"Un-Combine" individuals/persons; or, in some cases, "Restore" the "Deleted" (or better "Archived") individual/person; and, then work from/on the separated individuals/persons.

But ...
That said ...

That is just my thoughts.

Brett

.

LegacyUser

Abigail Mae Hardy said: Jordi and Brett,

Thank you for your thoughts and suggestions!

I have been on FamilySearch now for just over seven years. I have had to undo messes that have been created by other people (just like Jordi). Sometimes, there is no simple unmerge solution because I am not the one who combined the people and sources not just people have been added to the situation. This is why I think a split feature would be so lovely! I would be a clear and concise way to clean up messes that currently require entirely new people to fix.

~ Abi Mae

LegacyUser

Abigail Mae Hardy said: Additionally on the topic of ordinances.

If the ordinances were applied to the person with incorrect relationships (such as sealings), wouldn't they have to be redone anyway?

LegacyUser

Jeff Wiseman said: Creating a new record for a person that was incorrectly merged into another is not the best way to handle this. You should either do an unmerge (rarely possible) or perform a restore on the person that was deleted via the merge. If you try doing this by ignoring the deleted (i.e., archived) record and not recovering it (i.e., by just creating a new fresh one), all of the history for that record will be lost. Furthermore, any ordinance records that were originally attached to the deleted record will stay incorrectly attached to the improperly merged result record and NOT on the brand new "fake" record that you just created to replace the deleted one that is sitting in archive.

Once you create a record it is IMPOSSIBLE to remove it from the system. Even a direct deletion of the record or an indirect deletion of it (i.e., via a merge) will never destroy that record. It will just archive it and move it out of sight. But it will always still be there in the database where it is possible to retrieve it along with its entire changes and ordinances history.

A PID is forever!

LegacyUser

Brett said: Abigail

If the "Temple" Work was previously done for both the individuals/person that were "Merged"/"Combined"; when, they are, either, "Un-Merge"/"Un-Combine" individuals/persons; or, in some cases, "Restore" the "Deleted" (or better "Archived") individual/person; then, the "Temple" Work "Reverts" BACK to the way it was prior to the "Merged"/"Combined".

If the "Temple" Work was previously done for ONLY one of the individuals/persons that were "Merged"/"Combined"; when, they are, either, "Un-Merge"/"Un-Combine" individuals/persons; or, in some cases, "Restore" the "Deleted" (or better "Archived") individual/person; then, the "Temple" Work "Reverts" BACK to that individual/person who had the "Temple" Work done, prior to the "Merge"/"Combine"; and, the other individual/person will simply become "Request" or whatever state that it was, prior to the "Merge"/"Combine".

With your suggestion, that is a very good question - who decides? The "System"; or, the User/Patron! I would not like the latter. It should be what is in "System" (ie. The "Temple" Work Database).

Brett

.

LegacyUser

Jeff Wiseman said: Not if a restore is performed on the PID that was incorrectly deleted via the mis-managed-merge. After performing the restore, all of the ordinances will be again visible on the correct PID

Unfortunately if You take a PID with ordinances complete and incorrectly merge it into another PID that did NOT have ordinances complete, the ordinances on the PID being deleted will migrate to the surviving PID in the merge. That means that the post merge PID looks like it doesn't need any ordinance work done! Since it is schizophrenic in that it is incorrecly representing two different people, the ordinances that are incorrectly migrated over during the wrong merge will now MASK the fact that the resulting person actually needs ordinance work done and it will sit like that for a long long time.

IF you correctly do an unmerge (or if that's not possible, a restore on the deleted PID), those ordinances will be removed from the post merge PID and returned to the original PID that has been restored or unmerged. This will effectively put the ordinances on the surviving post merged PID back to where they were. This is a good thing, especially if nothing had been done for the PID yet as now you (and the system such as Ordinances Ready) can now discern that fact and schedule the work to be done when appropriate.

LegacyUser

Abigail Mae Hardy said: So could there be a way to implement this idea where the system still decides?

That way temple work could still be done with integrity and with a semblance of order and splitting people could be less of a headache.

LegacyUser

Jordi Kloosterboer said: sealing would be but others not. the reason to restore other people if possible is so that the ordinances point to the original records. So say Baptisms done for person 1 and person 2, but then they merge. if you split we don't know where the ordinances go, but if you unmerge, we do.

LegacyUser

Jeff Wiseman said: Only if nobody changed anything on the surviving PID. If that is the case, an unmerge will replace EVERYTHING exactly as it was before the merge. If things have been added, modified, or deleted from the surviving PID, then it requires human intervention to perform a restore on the deleted PID and then cleaning up the surviving PID to remove the things that don't belong on it.

Please note that my all my previous discussion was based on the assumption that the schizophrenic PID exists because of incorrect PIDs that were merged as though they were the same person. If the schizo PID was created by just adding sources and information about 2 or more different persons to a newly created PID, then the cleanup is a little different. In this case you can just create a new PID and move all the sources, information, and relationships appropriate to one person over to the new PID record. You would then need to search for duplicates of each and merge those in a appropriate to attach any previously performed ordinances (frequently on IGI type records)

LegacyUser

Jordi Kloosterboer said: you misunderstood me. I do always try to restore first. Ill tell you the situation. Say person A was born 1801 and has sources and ordinances done, then another user comes along and puts other sources in there with other family relationships. Now person A is both person A and person B. You have to create another person for person B and move the correct sources and any vital info/ other info into person B and delete / change in person A. There was never a merge in this process.

LegacyUser

Jeff Wiseman said: Yea, sorry about that. I just realized it a short time ago in my response to Abigail. Oops :-)

LegacyUser

Jordi Kloosterboer said: Abigail, the feature you suggest sounds really good but in the end just wont be able to work with FamilySearch due to ordinances. On other sites where each record does not point to ordinances, this would totally work. I think an employee would say the same but lets see what they say when they read this.

LegacyUser

Jordi Kloosterboer said: lol nw

LegacyUser

Jeff Wiseman said: Jordi, I'm pretty sure from what we've been told here that even if an unmerge is not possible, a restore on the merge-deleted PID will restore the ordinance assignments as well (it just won't clean up the other incorrect information left over from the incorrect merge)

Besides, even if you DID know where the different ordinance events go when trying to do a split, you could not do much about it anyway as you have no direct control over it
:-)

LegacyUser

Justin Masters said: Ron Tanner has addressed this topic a number of times with regards to merging and what info is stored in case an unmerge is needed. It seems to be focused on the preservation of ordinance data in that case, but difficult to do when it related to sources or actions subsequently performed post-merge. When you unmerge, which of the post-merge source attachments go with the restored person?

And did they ever fix that problem where a Life Story portion of a person who is merged is deleted?

LegacyUser

Adrian Bruce said: Interesting. While I love a bit of drag and drop to save work, my initial enthusiasm for the suggestion is tempered partly by what I read above (I'm not a Church member by the way so don't see ordinance data but would not want to mess it up if possible).

Part of the issue that I can see is that the default implementation of drag and drop would move a whole event onto a new / resurrected PID - yet that's not necessarily a good model for what we want to do. It might be that both the date and place of birth match both the compound and the new / resurrected PID - after all, that might be how the confusion arose in the first place. In that case, if you were creating a new PID, you'd want to copy the birth details from the compound to the new PID.

But another item - the death event say, might need to be completely moved.

And that's before we think about cases where the place needs to be copied over but the date needs to be moved!

Yes, a bit of a shame but I'm having difficulty in just thinking how the drag and drop might work at an event level given the possible requirements.

NB - I haven't mentioned the different flavours of unmerging / uncombining people because they've been covered above, not because I don't think they're important.

LegacyUser

Jeff Wiseman said: Agree entirely.

Every problem should be reduced to its simplest form, but NOT simpler!

There is routinely a lot of damage being done in industry under the guise of simplification and making things "easier and faster". Some items are inherently complex, and attempts to band-aid them only shifts the problem into a more complex form.

When the implemented structure of the system is significantly different from the intrinsic (i.e., essential) structure of the problem, band-aid type patches will usually just shift the problem into a different form and/or place.

The vital events in the record are SUPPOSED to be derived from ALL the relevant sources, and NOT just the one currently being attached. Tweaking vital data while attaching a SINGLE source without having immediate visibility to EVERYTHING (i.e., all other sources and documented derivation logic) that has contributed to the existing vital values is a step in the wrong direction IMHO.

LegacyUser

Adrian Bruce said: "Some items are inherently complex..."
Yeah - sometimes it's complicated - because it really is complicated!

That doesn't mean we shouldn't stop trying to think about making things easier - we just need to realise that it isn't always possible.