New Merge process loses info in Reason statements.

LegacyUser

Robert Wren said: It appears the new merge process does not allow for transferring, or saving some info (reason statement). In this case I'm allowed to accept either side as the final, but if I choose the right side, the "reason statement" showing an ArkivDigital source becomes lost in the new record.

It would seem there should be some simple way to save it. (I did not NEED it as I already had that info in an attached source on the saved PID.) (YES, it should have placed as a source, rather than as a reason, but . . a merge should allow saving all pertinent info, IMO).

LegacyUser

Jeff Wiseman said: Yup. That's why I do not use the reason boxes for any kind of conclusion proofs. If I have a significant proof that I don't want lost, I'll put it in a note for that person's vital, and then make a reference to it in the "Reason the change was made" box.

It is too volatile because it's being used for two subtly similar but vastly different purposes. You cannot trust any conclusion proofs that you put in any of those boxes to be around for very long. With some effort, FS may be able to mitigate this some, but since the "Reason" boxes are essential structure anomalies, they will continue to have these odd types of behavior due to their schizophrenic nature.

LegacyUser

Paul said: I find it disappointing in a way that we can (even by accident) close the Detail View in the Vitals (and other) section(s). I, too, have taken to adding more detailed reason statements against the vitals, instead of elsewhere.

Even with no date and place, comments can be added against "Death" - because of there being a default "Deceased" entry. I often add something like, "Unable to find evidence as to whether the death was in late 1867 or early 1868, as both sources for same name and area and give same age at death." So I can still get away without making an input if I do not want to enter an approximate date, yet want to show a clear indication of my findings. It's a shame comments can't be entered against the other vitals (Birth, Christening, Burial) if no date/place input has been made.

However, those users who choose to close the Detail View would be in the previous position, where we had to click on "Edit" to view such comments (as is still the case in the Relationship Events section, of course).

LegacyUser

Jeff Wiseman said: That's why it was always done by putting the derivation information into a Note titled with the VTAL that it related to--right back from the paper and pencil days. The "essential structure" of the problem has never changed, but we keep reinventing the wheel in how to deal with it :-)

Now if we can just get FS to provide tagging of NOTES from the person's NOTES list in exactly the same way that we already tag SOURCES from the SOURCES list. It would get a lot easier.

LegacyUser

ATP said: Jeff,

What NOTES list are you referring to? In the Collaboration Notes or is there another NOTES list I somehow am missing?

LegacyUser

Jeff Wiseman said: Yes, the ones that have very inappropriately been placed under the collaboration tab (they are definitely NOT specifically collaborative in nature any more than any of the vitals are). The Discussions are a modified type of note that was intended for collaboration, but IMHO, it wasn't thought out very well and so they just don't work very well. The experiment don't go quite like it was intended. Discussions were put under the collaboration tab and since they didn't want another special tab for notes, they put the Notes there also.

Every genealogical program out there including pencil and paper have always had a collection of notes associated with a given individual. In the FS world they have them too. However, those notes have been totally diluted by the "Reason" statements, Discussions, and other things to the point that we have folks here wondering what the notes are supposed to be used for. It's getting to the point that there are SO MANY places to record something, that there is no longer a standard place for a given set of documentation where everyone would know where it is.

Since all programs have them (i.e., person notes), moving data between different genealogical databases is very easy. However, when you use the special proprietary items like "Discussions" or "Reasons something is correct", they do not convey to other sites because they are non-standard.

LegacyUser

Brett said: Jeff

'Yes', that is WHY I put the SAME "Reference"/"Point" EVERYWHERE possible.

If, it is important enough ...

eg.
- Life Sketch
- "Reason Statements"
- Other Information - "Event" or "Custom Fact"
- Collaboration, both, "Notes"; and, "Discussions"
- Even included in "Sources"

Another User/Patron CANNOT say that they MISSED the important "Reference"/"Point" if it is 'plastered' everywhere (or, deny they saw it) - BUT, unfortunately, (very apologetically) some still do.

Brett

.

LegacyUser

Paul said: As discussed in another thread. it is probably important to always add the ID of the individual concerned when adding a Note or Discussion item. If I just put "Identity of John Brown" as the title of a Discussion item on the pages of two individuals of that name, it proves highly confusing if the two John Browns are later merged. Two identically titled items - which applied to what individual before the merge?

Drifting off-topic, but in response to Jeff's comments, I am quite okay with Notes and Discussions being in the Collaboration section - though probably because I am inconsistent about their use.

Generally, I add a Note as (hopefully) a short term item, e.g. "Unable to find John Brown's death in Yorkshire, 1881-1891: appears to have died before 1891 census". However, that would be collaborative in nature if another user was searching for the same death.

With Discussions, I definitely use this area when I want to make sure another user can't delete my comments - so the remarks could even be along the same lines as a Note. The problem with Discussions comes when I am no longer around to delete/edit them - with or without the implications related to a merge, they remain there "forever", regardless of how irrelevant they might become in future.

LegacyUser

Jeff Wiseman said: Paul,

There are MANY problems with discussions due to their side effects and you (like many others) are not actually using them the way they were meant to be used. You have found a niche application with the side effects where you'll not be able to track any of what you do on them, and when merges occur, they will move on to other PIDs. If they are bad merges, then NOBODY will be able to clean them up during a fix, and you will likely not be aware that there is a problem where you get notified to fix them! Discussions are a disaster and should be removed. The funny thing is that the only people objecting to this proposal are those that DO NOT use the discussions as they were intended. Instead they are using them as a permanent, Read-only bulletin board where they can throw their opinions out to the world (right or wrong) without them disappearing or being removed.

Although Notes can be temporary, most commonly they are used in a permanent way containing the detailed proofs of conclusions or life sketch snippets, always in a consistent place. In FS, changes to them will also cleanly show up on change histories, along with the reason they were changed (changing just a Reason statement in a change history is problematic as far as change histories go. There is no way to add a "Reason for change" to a previous "Reason for change" that you just modified.

Brett,

Ignoring the virtual locations produced by redundancy and backup functions, critical data should ALWAYS be stored in one place and one place only (consider it a master location). This location should ALWAYS be intuitive and easy to find by anyone looking specifically for it. If someone wants to know WHY a conclusion (e.g., a Birth date and location) have been recorded, there should be a perfectly obvious location directly accessible FROM THAT CONCLUSION where ALL of the derivation logic is documented in one place. They shouldn't have to go the the change history logs (which are about changes and NOT the key place for conclusion logic), and search back through that log for ALL the changes made to that conclusion/vital in order to understand why the conclusion was made.

Anyplace else where that derivation logic is pertinent should only reference the main data.. If the main document is changed, it can be seen everywhere.

If you start replicating the same information all over the place by creating totally disconnected clones of it, you are going to eventually get conflicts between them. If you must update the information in one, you now have to update ALL of them!

What's WORST is that if someone else comes along and sees a flaw in your logic and tries to fix it, they are now faced with trying to find all of the other places that you hid the information in! Furthermore they can't correct your discussion (although they CAN do a response with the corrections that now YOU cannot delete).

It's a huge hassle. Cloning of data for purposes other than physical redundancy (which this is not) or backup purposes (which this is not) should never really be done. It is a bad practice from the start.

Anyway, this is why providing the ability to Tag notes to conclusions would be very beneficial.

LegacyUser

Paul said: I'm a little wary about the tagging function, Jeff. After undoing a merge I usually remember to detach all the sources that no longer apply, but it is very easy to overlook all those tagged events - relating to residence, etc. - that still need to be removed from vitals / other information sections. Also, some of the information tagged against a birth, can often makes no sense at all. (e.g. a reason statement made in the source linking process is often meaningless when carried over to the person page from a census source.)

The joy of copy/paste is one can lift comments (made in Notes or elsewhere) and place them as reason statements against the vitals data.

LegacyUser

Jeff Wiseman said: When you remove a source, all of the tags from it to conclusions are removed with it, so it is probably a good idea to check all of the conclusions that have that source tagged to them before removing the source. But yea, I forget those too, especially when I am retrieving a deleted member of my ancestry from a bad merge into another family that I have no relationship with.

If you leave those inappropriate changes to vitals in the original surviving PID, the Duplications engine is going to keep harassing you about "that 'duplicate' over there"...

LegacyUser

Paul said: Jeff

I believe from your comments you can see my point, but just to illustrate it clearly (perhaps as a reminder to others). In the screenshot, you can see the detail about an 1837 birth (in Vitals) and the 1871 census residence (in Other) still remain on the page after I have removed the 1871 census source that caused their display in the first place.

So if I have detached a source I still have to remember to delete the detail on the person page, too. However, this is possibly going a bit of-topic, because I am not illustrating a situation following a reversed merge, just the GENERAL situation after detaching a source. I haven't tested what happens in the specific circumstances of an "Undo merge" (Restore person) exercise. Hope this makes sense!

Illustration of how details remain on the person page, which have been carried over to person page when source is attached, but do not disappear after the source is removed, as is the case here. (General situation - not confirmed necessarily related to merge process):

LegacyUser

Jeff Wiseman said: supposedly the Undo Merge function will return both PIDs to their pre-merge conditions. It's the more common Restore function that will cause this.

Anyway, that's why when you are manually having to remove "pieces" of the deleted PID (that you are restoring) from the old surviving PID, you should do it before removing the source.

LegacyUser

Paul said: Thanks for that, Jeff. When I undertake this procedure in future, I must try to follow this advice, then concentrate on what stays on the pages of the ID of the person who survived in the original merge, and what disappears and goes back to the Restored person.

LegacyUser

Paul said: Of course what could be causing me confusion is the situation where sources have been attached to the incorrect ID BEFORE the merge. Unless the individual dates are thoroughly checked, one could gain a false impression that these incorrect attachments were the RESULT of a merge, rather than the fact they might have PRECEDED it. That does seem to be a reasonable explanation as to why sources are "remaining" with an ID, rather than "going back" to the restored one - i.e. they were never on the restored ID(s) in the first place!

My confusion has probably been compounded by the fact that I am often dealing with multiple merges into one ID. On a number of occasions I have experienced careless users merging up to five IDs, relating to totally different individuals, on the same day.

LegacyUser

rotkapchen said: Ditto