Avoid the Loss of information that occurs during a name change
When someone change the name of an individual, the previous name is stored in the individual history, but not in the Alternate Names section
If it's not there, I think it would be wise to add it as an alternate name, so it could prevent loss of information. I think your system make good use of those alternate names !
When a merge of individuals occurs, you have to choose the Main Name to keep for the resulting individual. The other one seems to be deleted. I think it would be wise to convert this lost Main Name into an Alternate Name of the resulting individual if it's not already there, so it could prevent loss of information.
Thanks :)
Jerome
Comments
-
The name is not deleted. Here's an example of a woman who has been merged multiple times, over the course of 5 years. Some of the merges were with the same name, others were with a variant. All those names are still visible in her changelog.
3 -
If you believe that the name you're changing from is also valid, then you should of course enter it as an alternate name -- but how often does that actually happen? Most of the name edits I make are corrections, such as changing a Latin oblique case to nominative (or the vernacular), or changing the spelling from how it was misindexed to how it was actually recorded. Automatically sticking the erroneous name under Other Info would be a Thoroughly Bad Thing in those cases, and even an optional move would be mostly just an annoyance, for me. (Kinda like the "birth name" entries on the legacy data that I spend a lot of time cleaning up.)
3 -
I agree with you Julia, not all names are valid. But I think that when someone change a name the system could ask if it's a good idea to convert the previous name into an alternate name :)
This is not what I mean Aine ! Of course all names as been preserved in the the change log ... BUT NOT as alternate names !!! Alternate names are use by the system in a useful manner to help genealogists, those names MUST be preserved there :)
I must also add that, sometime, a name that seems not valid coul be, in fact, a useful alternate name. The previous user who entered that name could have find it on a document where it was badly written. However, the system contains a lot of documents with badly written names ... so this is often useful to preserve those as alternate names :)
1 -
Many of those names that have been merged away are not true alternates. As Julia mentioned in your other thread, mistranscriptions should not be preserved as alternates. And, again, there is no LOSS, when all is visible in the changelog.
2 -
I'm with @Áine Ní Donnghaile on this one. Alternate names should be thoughtfully added. Multiplying alternate names automatically via merge would in many cases proliferate unhelpful alternates. It's not difficult to add an alternate if it is truly valuable.
6 -
My fear is that keeping the previous name as an alternate in merges would lead to the same sort of data clutter as we currently face in the couple relationship area, where the same event can end up listed a dozen times, with slight variations on place and date. Many users automatically and unthinkingly take the computer up on every offer it makes for adding conclusions, so it doesn't matter that these transfers of data are all optional.
As Alan said, keeping a name should be a deliberate action.
4 -
When merging, we can choose wich alternate names we keep from both individuals. I think this idea should be applied to the main name. Why not offering the possibly to keep or not the Main Name of both individuals. It costs nothing to let the user chooses what he prefers.
The system uses alternates names to look for information to suggest documents. If a name is only in the change log, does the system uses it to make suggestions ? I don't know. I'm not saying that idea is perfect, just saying that I would like to have this opportunity when merging.
0 -
Record hints are created based only on the primary name and any alternate names (and other data for the person) -- nothing in the change log is used for generating record hints.
I suppose that if this suggestion to move a primary name to become an alternate name were optional, it wouldn't have the significant problems that could occur if it were automatic. Of course, making it optional would certainly have significant costs -- it would have to be designed and implemented and tested for both the website and the mobile apps (engineering costs) and it would add some complexity to the user interface (user costs). Are the benefits worth those costs? That's a question that the appropriate product manager(s) would have to decide.
2 -
Your are the judge of this idea, I only suggest it. I can bring another view of why this idea could be interesting. Two users using the family tree decide to create the same exact person.
The first user name this person Amanda B.
The second user name this person A. Bell .
Giving the dates and locations related those two people, your system suggest a merge.
A third user see the warning and decide to merge the individuals. During the merge, one of the main name is lost. The resulting person is Amanda B .
The second user come back to the family tree and can't find A. Bell, so he recreate it ...
1 -
@Jerome Blier Most of the participants in this forum are other users, just like you. It's not "our system."
0 -
@Áine Ní Donnghaile , I thought that @Alan E. Brown was more than just a regular user because he speaks like someone from the dev team of the application :
... website and the mobile apps (engineering costs) and it would add some complexity to the user interface (user costs) ...
0 -
@Jerome Blier As I said, it's a product manager who would make those decisions. I know how development processes work, but I'm certainly no product manager.
1 -
On the Amanda B versus A. Bell example, the hypothetical problem -- of the user not being able to find A. Bell's profile and therefore re-creating it -- shouldn't arise, for two reasons: one, a properly researched merge would change the profile name to Amanda Bell, and two, all of A. Bell's relationships would still be there, so the user would need to be truly oblivious to add "A. Bell" to a family that already had an "Amanda Bell" (or Amanda B, if the hypothesized third user was sloppy/lazy).
2 -
@Julia Szent-Györgyi , in my example, A. Bell was created without relationship (the user may create relationship later). For your other reson : properly researched merge would change the profile name to Amanda Bell, I don't know what you mean. As far as I know, when the system look for someone matching the individual you try to create, it uses the Main name and all alternates names, but not the names that are only in the log of old Main names.
0 -
It wouldn't be any part of the system changing the name on the merged profile to Amanda Bell. It would be done by the user doing the merge, most likely before starting the merge process, while researching whether the two profiles really were a match.
1 -
The problem is that the operation rely on the user that does the merge ! If it's a skilled genealogist, it's perfectly logical ... but if it's a random user that experiment the merge operation for ther first time, what you say could never happened !!! As a Web developper, I could ensure you that if the system could prevent easily users blunders, it should do it !!!
0 -
"... if the system could prevent easily users blunders, it should do it !!!"
I'm afraid I get a bit worried about that sort of statement. I know this is going to sound like we've been here for ages and know it all, but... We have seen all sorts of requirements that appear simple, with simple solutions - that run into serious issues because the volume of data in FS is such that even a tiny percentage of an error rate results in sizeable numbers of errors.
I thought that we'd agreed that there shouldn't be automatic creation of Alternate Names because we'd just end up with pointless Alternates created just because of a difference in spelling.
That means it needs to be up to the user doing the merge to decide if anything needs to be carried over to the resulting merged profile. If the system actually asks the user "Shall I create ...?", we know that we'll get lots of people saying yes simply because the computer has suggested it and the computer is never wrong. (No, I'm not being sarcastic - I understand that some people have actually been instructed to accept all hints and suggestions). Excessive acceptance of suggestions will result in the same puddle of pointless spelling differences.
I'm certainly concerned about new users getting merges wrong - but the answer to that is training users and not letting them loose on merges until they have passed some sort of checks. If the computer could do it all, we wouldn't need to be here. We do need to be here and we need training for these sorts of things.
1 -
@Adrian Bruce1 I understand what you mean about automatic creation of Alternates Names. The question that still remains is : If we can choose wich alternates names, events, parents, children, sources we keep from BOTH individuals in a merge, why can't we choose to keep one main name or BOTH main names in the merge ?
That seems the only exception ! By default, the system could suggest to preserve only one of the main name and the user could click to add the second one ? Actually, each time I merge individuals, I must not forget to manually check the main name log after the merge to restore one of the main name as an alternate name.
What's your opinion ?
0 -
Somewhere in the back of my mind, I am fairly certain that "we" discussed the ability to promote Alternate Names to the Vitals (main) Name. This would need to happen in such a way that the Tagged Sources, history, comments, etc, all moved with the name in question. So if I wanted to demote a Vitals Name in favour of an Alternate Name, I'd go to the Alternate Name in question and mark it as the Vitals (main) Name. That new Vitals Name would have all the stuff (including tagged sources) that the Alternate Name had. As a consequence, the previous Vitals Name would become an Alternate Name and the tagged sources etc with it would be moved from the Vitals Name to the new Alternate Name.
As I recollect this was suggested to take the risk out of deciding which version of a Name to use - just press a button and nothing is lost, rather than start hacking, sorry, editing, Vitals Names. And equally, a button press would revert so no need to get uptight about exactly which spelling is used. Our feeling was that, because of the workload, too many people had too much emotional capital invested in which name was used whereas if it was just a button press...
If this Name Swap / Promotion facility were available - including Source Tagging - then this facility would assist the merging process.
Currently, the options for a Vitals Name from the Possible Duplicate profile are to ignore it or wholly replace the existing Vitals Name in the Surviving Profile.
I suggest a third option "Add As Alternate", which would add the Vitals Name from the Possible Duplicate profile to the Surviving Profile as an Alternate Name complete with all the notes and tagged sources it had as a Vitals Name on the Possible Duplicate.
After the merge is complete, then the names can be rationalised if necessary (I vehemently dislike doing anything in the Merge process other than merging. One thing at a time please.)
This proposal avoids any automatic processing. It doesn't give any hints that the "Computer Says Yes" people are too eager to accept. It allows all name data to go onto the resulting profile.
0 -
I vehemently dislike doing anything in the Merge process other than merging. One thing at a time please.
Ok ! What you call merging process is what I call BASIC merging or easy merging. So, everything that has the same essence can be merged together : alternates names, people (parents, spouses, children), events and sources.
Currently, the options for a Vitals Name from the Possible Duplicate profile are to ignore it or wholly replace the existing Vitals Name in the Surviving Profile.
Exactly, this is the LOSSY part of the merge process (that was the title of the thread). You can keep only one vital name. Since you only want to do basic merging, the other Vital Name will go to sleep in some change log. The other Vital name should not go to sleep in some change log, this name is way too important for that ! He should still play an active role in the new profile because you use active names to query the database for usefult data !!!
The only way to achieve that is to demote that Vital name to an Alternate name. It's essence changes but it is not sleeping in a log :) Then, we have a FULL merge, nothing has been forgot. That's way harder to achieve, but in a large-scale system, benefits are awesomes.
More people find their family because more names have an active role when queries are done to associate documents whit people. A dream comes true.
I am fairly certain that "we" discussed the ability to promote Alternate Names to the Vitals (main) Name
Sorry. I'm totally new to this community.
1 -
Yes,
My French relative was born Leo Gagnon (name can be angelized MANY different ways), his mother died when he was a baby and he was raised by maternal relatives so he became Leo Cassibo (also anglicized MANY different way).
Leo suffered a great tragedy that was reported in newspapers internationally. But the first source reporter called him Neil Cassibo. Neil is NOT at all in any way his name, but, if you want to research him to the fullest extent you need to look for him in documents with this incorrect name as well as all the mis spellings and name changes. Backs of photos would have their casual nick name.
Fields for "Alternative names" and "otherwise known as" and "documented name" would be nice
I usually put the other names, nick names etc in the suffix part of the name.
0 -
2
-
@BJC1234, as Áine says, you don't need to resort to misusing the name fields in the Vitals box. A profile can have as many alternate names as you want. In fact, that's kind of the whole point of this thread that you replied to: the suggestion is for a more direct connection between the single name in Vitals and the possibly-many names in Other Information.
2
