Incorrect assignment of information after merging
See for example KC4K-XQY. The christening date is from another person. I can't control it and don't agree with the entry. I wish my name removed. This is a systematic error and should be corrected because it violates personal rights.
Many thanks and regards,
Peter Heiniger
Answers
-
The great thing about the FamilySearch Family Tree is that it is fully open-edit. You can change an entry you believe to be in error and attach the appropriate sources as evidence.
1 -
This is a perfect example of why the system is designed to work the way it does, that is it working correctly, and that your name should be there.
Before you did anything to these records, there was one record with name, birth information, and husband and there was one record with name, christening information and parents.
You had two choices:
- Decide these were two different people and leave them alone.
- Decide these were the same person and merge them.
You chose to merge. Your name is listed against the merge because that was your decision and you are assigned responsibility for that decision.
During the merge you had two choices:
- Add the christening date to the surviving person.
- Do not add the christening information to the surviving person. (Of course, if the christening date was for a different person of the same name, you never should have merged them.)
You chose to add the christening information to the surviving person. Because you added that information, through the merge, you are declaring that in your opinion the information is correct for that person and you are assigned responsibility for the decision that you made. If you did not know if the information was correct then you should not have merged until you had done sufficient research to confirm the information first. If while doing that research you found that the christening was for a different person of the same name, then you would not have merged them.
After the merge, you hade three choices:
- Leave the christening information the way it was when you completed the merge as a declaration that you agree with the information.
- Delete the christening information because is does not belong to the surviving person.
- Correct the christening information because you know why the original information was wrong and you have the correct information.
Again, you are assigned full responsibility for the final state of the information, whether you keep what you put there through the merge, deleted what you put there through the merge, or corrected the information.
Family Tree is a public tree. Our actions there are public. And we need to be willing to accept responsibility for our actions. If you don't want credit for changing information through a merge, then don't be merging people. No personal rights are involved here. Only public responsibilities.
10 -
Your username was in the "most recently changed by" slot because you were the one who chose to replace whatever was on the "merge survivor" profile with that christening conclusion. (It no longer shows your username, as someone else has edited it.) If you disagreed with the christening conclusion, you could have chosen not to move it over during the merge; then your name would not have appeared with it (not even briefly).
6 -
And anyway, the date was correct. I found the source and attached it.
2 -
I disagree with Gordon Collett. I believe individual items like christening information should keep the name of the person who entered or last edited the information. I may not think the information is right, but if I don't have proof as to whether it is right or wrong, I don't want to eliminate it. Since I don't know personally if it is right, I don't want my name on it either.
0 -
@JMS, if you can't avoid moving a conclusion in a merge (because the other direction would result in even more such uncertain moves), then I suggest adding the previous contributor's username (and the date) to the reason statement. This is easiest to do before the merge, but can be done after by consulting the change log in another tab.
But the fact remains that moving a conclusion over to the surviving profile in a merge is a change to that conclusion, no matter how misleading it seems in the end result. But this is true of all such attributions, as I have learned sort of the hard way: I messaged the wrong person about a contribution because I failed to check the full history of the conclusion in question. (I asked "why this person" from someone who'd simply corrected a typo in the name.)
3 -
@JMS , it sounds like we do basically agree. Particularly in this situation. Since the the two profiles overlap only in that the name of the person is the same, if you did not do the research to prove that the christening information and parents truly were for the person in the other profile who had no christening information and no parents listed, then you would never have merged those two profiles.
The only time your name would have shown up was after you did the research to prove the merge was correct and then edited the surviving profile by adding that christening date. Since you would have done the editing, then your name should be there.
I agree with Julia that if you cannot confirm information then a reason statement is a good idea and you should include in it why you have been unsuccessful in confirming the information.
3 -
@GC, Your suggestion is already good. Since I match dozens of names with FS every day, I don't have the time for that. And your argument has no legal basis. However, the law prohibits attributing statements to a person that they did not make.
0 -
Oh, dear. I find this quite disturbing. If you are merging based on name only and not confirming by checking all the information on the profile that the two profiles really are for the same person, you are going to be conflating two different people into one on a regular basis.
I would recommend that you slow down and fully evaluate both profiles and confirm that all information there is correct by checking sources before merging. It is far better to only do two merges per day than to do dozens and have several of them be incorrect.
Regarding the law, I'm not a lawyer, but I doubt that if you were being sued for libel that a defense of "I was just quoting what someone else said. See, his name is on the quote. I have no idea if the statement was true or not." would be effective at all. You printed the statement (or in this case placed it on the Details page). You are responsible for it being there. Therefore your name goes on it.
3 -
This problem has been argued about for many years and most users can see there are two sides to the argument over the name that should be shown in such cases. Obviously it is open to anyone who thinks there is a legal aspect to the issue to take the matter further.
However, as suggested, it is quite simple to distance yourself from a data entry by adding a comment like: "Inputs by John345. Standardized only by Paul W, without confirming accuracy of data."
A reason statement like this explains that it was another user who was saying a piece of data (say christening event details) is correct, whilst a later "edit" (carrying your username - due to your carrying out a merge, or for any other reason) can include a disclaimer (regarding the lack of verification of the facts by yourself).
5 -
You must understand my motive. I am a member of two genealogical societies in Switzerland. FS doesn't have a particularly good reputation here, not as a portal and program, in which it is excellent, but because of the quality of the data, especially those that were entered a long time ago, when the technical possibilities were not as good as they are today.
On the one hand, there are still many duplicate entries, incorrect assignments and of course non-standardized data, both location information and family and first names. The former must also be standardized here, even if our American friends don't understand that. There is a legal problem about this, which I will come to later. I can't correct everything, but I can at least correct what is necessary for the temple ordinances. That's my priority and that's why I can't follow the well-intentioned advice.
If our archives FS allow the publication of digital copies, then they retain the copyright. A user of FS only receives citation rights. This means that he must correctly cite the source, namely the archive in question. Our archives value this and it is their right. However, unlike scientific publications, there are no requirements for such source references. I myself use this for church records: location, URL or address of the archive, title, period, volume number and page number. This source must be publicly available. It's not enough if you have to go to an FHC. It is also not enough to place links to other sites. You can do that, but these are not sources and FS shouldn't talk about sources. Of course, this is not the responsibility of FS, but of the user.
Thank you for understanding.
0 -
@peter.heiniger, your assertion that sources from other websites aren't sources makes absolutely no sense to me. What are you actually trying to say?
A source is anything that led you to a conclusion. If you get a phone call from your aunt informing you that your uncle has passed away, then you record the date and fact of the conversation as your source for your uncle's death. The fact that nobody -- including you -- can access that source in any way makes absolutely no difference.
Likewise for a church register or family book or city tax log: if you had to go to an FHC to see an image of the the register, or to a paywalled website for the family book, or even if you had to show up in person at the state archives to look at the tax log, if the information in one of them led you to a conclusion, then it's a source for that conclusion. How exactly you should cite that source is a topic subject to much debate, but in my opinion, any format that conveys the necessary information is fine. (What exactly constitutes "the necessary information" is also up for debate, but I think it boils down to "what it says" and "where I found it".)
It sounds like you spend a large proportion of your time on FS cleaning up legacy data: combining index-based twiglets into families, and attaching the index entries that generated the twiglets in the first place. I do a fair amount of that, too, so I know how tedious it can get. I also know the sorts of errors that those old indexes contain, and the sorts of errors that ill-researched merges introduce. I do not accept hints or merge possible duplicates without checking the images at minimum, and I always keep in mind that even couples with the same names may be different people. (I included screenshots explaining why this possibility is never far from my thoughts in my first Feb. 15 comment on a thread in the A-H group: https://community.familysearch.org/en/discussion/157166/help-reading-a-name-in-a-latin-record.)
To bring this around to the original topic of post-merge attributions, my experience is that when a set of duplicates was generated from two different "ends", you're going to end up "credited" with either a birth/christening or a death/burial. I choose not to worry about it: 90% of the time, the previous contributor was "FamilySearch", twelve years ago, and burying that in the change log doesn't lose much, especially if it's still there on at least one field. (Any semi-experienced user of FS can recognize that if the profile's sex is attributed to FS in 2012, then the entire profile originates as legacy data imported from a previous system.) If I'm finishing a partial cleanup by a different user, then I sometimes record that username in the reason box, just so it's more easily visible than it is in the change log.
4 -
This community is intended for suggestions. That's why I would like to make a wish to FS. For example, FS presents the ancestors in a pedigree, but calls it a family tree, which is understandable but not entirely correct. On the other hand, a time-reversed representation, as a family tree, would be a very desirable option. This would allow to include information about the origin of a dynasty, the meaning of the family name, a historical overview, etc., which is not now possible in a practical way. In family research, it is common to research dynasties, which means starting with a specific person in the past and listing their descendants. This is the safe way to do family research in ancient times. It should be possible to start a dynasty from any person upwards, for me, for example, from the first place of residence, for an emigrated family from this dynasty from this one.
On my homepage www.newfamilyday.org I have shown a little about what I want from FS. The site is not functioning properly now because it is hacked and abused despite captcha etc but you can download files. I call the dynasties there family organizations. Take, for example, the Strub family from Läufelfingen, which I am currently working on, and download the zip file from the genealogy. You will then also see how laborious filiation can sometimes be and what information you have to gather for it. This will also be a big challenge for AI, which wants to use FS in the future. On my site (Heiniger) you can see a short historical summary, unfortunately in German, and for the Bohner family there is a discussion of the family name. (I could suggest around 50,000 such projects only in our little Switzerland. I have almost 100 in progress myself. Each one lasts six months or more and I'm 82 now.)
Thank you for your interest.
0
