Query or diagram to list all the PIDs that contribute to an existing profile

LegacyUser

Adrian Bruce said: If multiple profiles have been merged together incorrectly, then my understanding is that the ideal course of action is to restore all the merge-deleted profiles and shift any necessary data from one to another.

Sometimes finding the PIDs for those merge-deleted profiles is "easy" - e.g. if all have been merged into the current, surviving profile.

Sometimes this finding process simply isn't practical in any viable timescale - I suspect that this is often because profiles have been merged into other profiles, which have been merged into other profiles, which have been merged into other profiles, and so on ad nauseum. Unravelling that lot may feel impossible especially if the oldest merges are deep below multiple layers of merge and consequent "Al Change" displays.

Bear in mind please, that for those of us who are not Church members, the possibility of creating a new, empty record is attractively easy - we can't see (I don't want to see) any issues with ordinances that remain merged.

Suggestion - For any FS Family Tree profile, it should be possible to create a query or diagram that shows all PIDs that have been, directly or indirectly, merged into the current profile. The "contributing" PIDs must be connected in the diagram / query in such a way that we can see which order to restore the merge-deleted PIDs (I am assuming that the order of restoration is important. If not, then the connections may not be as important?)

The diagram would look, I guess, something like an inverted pedigree (current PID at the top?).

Not totally sure what ought to appear against each merge-deleted profile - clearly PID must appear but probably name and life dates would help.

LegacyUser

Tom Huber said: Hm. I thought I had responded to this thread already, but...

This should be available already, since any ecclesiastical vicarious work has to track all the PIDs that contributed to an existing profile (through merges) in order to display the earliest valid information. I have to wonder if this is a separate routine, but even if it is, I believe it should be fairly easy to implement for displaying the contributing IDs, even going back into the previous (nFS) system. The IDs from nFS may be a problem, though, and the records were not "merged" like they are today. They were combined.

The profile should contain all merge-deleted profiles and should display the same information that we see on the merge event in the new Change Log.

LegacyUser

gasmodels said: There is not much value in knowing the ID number of those combined in nFS because there is no way to look at those records individually or to recover those records by ID number. It would be relatively simple to go through all merges in the change log of the existing record as well as all change logs of the deleted record and recover all ID's that are shown to have been merged. Manually It is relatively straightforward to accomplish so I think software could be written to accomplish the same thing. The additional question is what other information would you like to have in addition to the ID number. On the deleted records without restoring you can presently see only Vital information - relationships do not display directly (they can be seen in the change log of the deleted record). I do not know if information besides the vitals can easily be recovered but somehow we need to specify at least the minimum information we would like to see.

LegacyUser

Tom Huber said: Perhaps you are correct, gasmodels, about the ID number of the combined profiles from nFS, but I do not know if those combined profiles that are equivalent to the merge-deleted profiles on FamilySearch we kept as they were at the time the two records were combined. Only FS could let us know if this was the case, but because of the way the vicarious data is maintained, there has to be some kind of track record that identifies all of the ordinances involved with all the merges, regardless whether it was the nFS tree or the FS tree.

LegacyUser

Adrian Bruce said: From my non-LDS viewpoint, I can see no advantage and every frustration in knowing the contributory PIDs that were combined away in nFS. I can't see their details, I can't restore them.

So unless anyone knows better it doesn't seem to make sense to add such data to the proposed facility.

LegacyUser

Tom Huber said: We really don't know if those profiles which were combined into the current profile back when the tree was under the control of nFS are truly gone. If they aren't, then hopefully, FS will be able to provide the means to restore those trees, despite the fact that there may be little in the way of supportive sources (nFS had only a rudimentary sourcing system).

LegacyUser

Adrian Bruce said: Oh, OK, if there is something that could be done, then it would be worth exploring, presumably as a second stage? (Because I envisage that my original request could be done by walking up and down the Change Histories in FSFT without the need to go further)

LegacyUser

Jeff Wiseman said: Just an observation here, but a list of just the PIDs that have all "contributed" to a surviving PID by itself wouldn't seem to be of much use. In fact, it could be very misleading to state that all of those PIDs "contribute" to a given surviving PID.

Ignoring the nFS issues that we really can't do much with, anytime that I have needed this type of information, I have ALSO always needed to know the time, structure, and sequences of their combining as well as adjustments to vitals made afterwards to PIDs in order for any of those numbers to have any value to me at all.

Now perhaps a graphic list in the form of a "merge tree history" of all the PIDs, with any PID listed being a link to that PID record (even the archived ones that were deleted via the merges) might have value, but I still see complications here.

For example, if PID A were merged into PID B, you end up with PID A archived and PID B has become PID B' (i.e., something different from PID B even though the PID numbers are the same). So at this point you would say that PID A is contributing to PID B'.

So now, if PID A is then restored from the archive (undeleted), You would still say that PID A contributes to PID B'. However, if the person that restored PID A *ALSO* did the cleanup on PID B' by removing PID A specific information (as they SHOULD), you can no longer state that PID A contributes to PID B' since those contributions have actually been removed from PID B'.

This is further exacerbated as you move farther back through the merge tree history. What if a PID that was merged in prior to 3 other merges? If the contributions of that long lost PID is removed from a current surviving PID (because they "obviously don't belong there"), then can you really say that old PID is really "contributing" to the current surviving PID?

So in addition to the merge history, you also need to interpret all of the non-merge related changes that have been made all along the merge tree to really determine which PIDs "contribute" to a given PID. All of the information needed to make such a determination is far more than a computer algorithm could determine-it takes a human being to decide such things. Furthermore, all of that information is not even in the current change history in a way that easily enables analysis so that such decisions can be made.

So I suspect that a list of PIDs that "may be contributing" to a given PID may not be worth much without all of the other information in all of the change history files that go with them.

LegacyUser

Adrian Bruce said: "However, if the person that restored PID A *ALSO* did the cleanup on PID B' by removing PID A specific information (as they SHOULD), you can no longer state that PID A contributes to PID B' since those contributions have actually been removed from PID B'. "

1) I think that I was presuming that if PID A were restored, then it would no longer be merge-deleted, so would no longer appear in the B' diagram of contributions. Indeed, anything that had contributed to PID A wouldn't appear as a contributor to B' either.

So it's actually, "it should be possible to create a query or diagram that shows all merge-deleted PIDs that have been, directly or indirectly, merged into the current profile."

NB - this does not mean that the original merge no longer appears in the Change Log. That original merge needs to remain because a Change Log is a Change Log. (Might that give rise to some confusion when comparing Merges in the Change Log to the "contributing" diagram???)

2) "a list of just the PIDs that have all "contributed" to a surviving PID by itself wouldn't seem to be of much use ... I have ALSO always needed to know the time, structure, and sequences of their combining as well as adjustments to vitals made afterwards to PIDs in order for any of those numbers to have any value to me at all."

Very possibly. My idea is to provide a navigation tool, not a full psuedo-de-merge tool. I'm sure that the Change Logs will still be crucial - this is more to help me find the appropriate entry in the correct change log rather than me not knowing which Change Log contains which merges. Some sort of indication in the navigation tool about when the merge took place would seem an excellent idea in order to find the correct position in the correct Change Log.

3) "If the contributions of that long lost PID is removed from a current surviving PID (because they "obviously don't belong there"), then can you really say that old PID is really "contributing" to the current surviving PID?"
Fair point - however, either way you need to look and decide what to do and right now I think I'm liable to get lost finding something to look at. So the "contribution" of such a multiply merged PID may actually have been lost but it still might have contributed, I still have to check, which means I still have to find the merges in the multiple change histories.

4) "I suspect that a list of PIDs that "may be contributing" to a given PID may not be worth much without all of the other information in all of the change history files that go with them"
Absolutely - to reiterate, I envisage the PID list / diagram to be just a navigation tool and I assume that I'd still need the relevant Change Histories - it's just that I'd know better what went into what and I'd know that my failure to find PID X in the Change History of PID Y was not due to finger trouble on my part, but because PID X had been earlier merged into PID Z, before Z was later merged into PID Y.