gideon jacobus van zyl - Conflicting parents as a result of a merge

Hi Sharon,

In this case, there was a whole family that was identical except for agreeing on who the right Albertus Adriaan van Wyk is. The new user, carel albrecht de jager, has a tree that goes down to contemporary people, whereas the existing tree is part of the big and was created by Leone Gardner whose name I've seen a lot so I assume as experience in genealogy.

If I were to guess, I would guess that Leone has it right and the correct Albertus is b3c2d11e8f4, but absent any evidence or additional information, I decided to leave the merge at this state and not attempt to decide who is the correct father.

Any advice / help would be appreciated.

Divon

Hmm. I see what you mean... Thinking. The problem of the created tree conflict does remain someone's problem to resolve though. The question is - whose?
Are you saying this was just the the last profile in a whole family line that you merged in?

Hi Divon,

I think the problem could’ve happened with the 2 merges you’ve done yesterday on Dina Maria Wouterina van Zyl (van Wyk), e2f3g2 ‘s profile.
https://www.geni.com/merge/resolve/6000000032349059955

When I come across a possible match and notice conflicts like this I usually just notify the managers and ask them to have a look at the match and don’t actually complete the merge.

After quite a search I found the Estate of one of the Albertus Adriaan van Wyks.
This is actually mentioned on Dina Maria Wouterina van Zyl de Jagers profile.
“latee Albertus Adriaan van Wyk ( 21516 )”

The reference number for her Estate is also mentioned on her profile but is unfortunately not searchable yet. VAB Bloemfontein Estates - Ref : 1020.60 Filed 12 August 1960

The death notice which I’ve added to the profile, Albertus Adriaan van Wyk, b3c2d11e8f4 should help you to sort out the conflicts on the profile as it shows the names of both his parents and 2 wives and 5 children.

I hope this will help you to solve this problem.

In trying to find anything to confirm Dina Maria Wouterina's identity I found her mothers estate. See on the profile. But there is also a problem with a merge. I did not update any of the details as shown on the death notice.
Maria Magdalena Emmerentia Beukes, e10f4
Sharon Doubell this merge may need to be undone.

Wow, I'm on a roll tonight! Found Dina Maria Wouterina van Zyl (van Wyk), e2f3g2 's Estate as well.

i do hope all this will help you.

Private User
You said “Any advice / help would be appreciated” which I gave to the best of my ability, now I feel I need to explain why I objected to the fact that you very often leave conflicts on profiles you merged for other users to clear up.

Because we share an ancestor from quite a prominent South African family, Elizabeth Maria Ravenscroft , I would guess about 80% of the merges you do and leave the conflicts unresolved or where there are conflicting parent like in this case, end up in somewhere in my merge centre.

You know how many merges you do almost on a daily basis. Now imagine for every conflicting profile it takes me close to a day to find sources to correct the problem. This same conflict also appears in many other users’ centres. Therefore a couple of people may be trying to solve the problem at the same time. When a mistake is discovered we need to involve curators to help undo the merges. I’m not sure how long that takes but as you can see, many hours are wasted on correcting one single conflict.

Most of the profiles I manage are very well documented and I’ve come across conflicts created by merges you completed where I had to go back to the source documents and correct the changes you made when merging profiles. I feel this is a total waste of time as the profile was correct in the first place.

Now I realize it’s Genis’ aim to create one single big tree but I’m quite sure it’s not their aim to create hours of work for other users who need to sort out the conflict left behind by a single user.

I do appreciate the time you spend merging duplicate profiles but I feel you should be much more careful when merging. Like I said in my first message “When I come across a possible match and notice conflicts like this I usually just notify the managers and ask them to have a look at the match and don’t actually complete the merge.” This way the profile manager, who usually knows the family, can make corrections if need be before any conflicts arise and thereby saving hours of work.

I think before you continue with any other merges you should look at your own merge centre and try and resolve the conflicts created by yourself. I am sure the profile managers and curators will all be willing to assist and if you are not sure where to find source documents you may feel free to ask me to assist.

Regards
Charmaine

I am posting this here because it often seems to me that users are unaware of their https://www.geni.com/list/matches - which is where data conflicts/tree conflicts etc. are listed - how to work with the conflicts is outlined at https://www.geni.com/projects/Data-Conflicts/37473 and the other supporting projects. What Charmaine says is so true - we spend HOURS sorting out the trail of tree and data conflicts left behind by energetic and incomplete merging! If people do not know the answers or have the time to deal with the conflicts please could they contact the managers of the profiles drawing their attention to the merge that has been done and asking them to look at the conflicts involved - see "View nearby conflicts" under the "Actions" menu on the profile page.

Thanks guys for this great discussion.

So here's the question, and would love your thoughts on it. There are really two sources for the South African tree on geni. One is from the community of experienced genealogists, a few tens of people. When this started around 2007-2008, the focus was on the 17th and 18th century part of the tree, and as that got filled out, now most the work being done, in terms of profiles added and connected, seems to be in the 19th century. Obviously, the number of profiles in the 19th century dwarfs that of the earlier times. There are probably less than 20-30 individuals that have contributed the vast majority of the "professional" tree.

The second source, which possibly contributed even more profiles to the South African tree overall, are the thousands and thousands of individuals that enter their own personal family trees, who contributed the vast majority of 20th century profiles, who, once complete will dwarf in numbers those of the 19th century. However, due to lack of experience, these often have errors, esp as they attempt to build them up into earlier centuries.

One of the great achievements, I think, we have as a community, is that we have brought in most of these personal trees and merged them into the big tree, allowing the general public to easy find relationships between living people, as well as learn about their ancestry. Ultimately, that is the value of all our effort. If its not useful, its as if it doesn't exist.

I think I have made my humble contribution to this by doing a bunch of this merging work (that no one else is doing on this scale to my knowledge) - many many thousands of them, I don't know how many, but let's say 10,000 just to put down a number (but it could be more). The vast majority of them were simple and clean and without conflicts. If I had to go chase sources for each of these, as you guys suggested I do, I would obviously just not get anywhere remotely close to these numbers, as tracing sources and resolving conflicts is very hard and time consuming, as pointed out above. And then we wouldn't have the beautiful big tree we have today.

I am not avoiding doing this because I am lazy (even though I am :) ), and dumping the hard work on others, but rather because I think that merging in a sizable tree of a 20th century family and connecting all its ancestors into the big tree is hugely valuable, even if there are conflicts in data left here and there. We don't have to jump and solve them all right away, because solving them is very difficult and time consuming as pointed out in this thread. Its ok if they get resolved slowly over time - in a year or in 10 years or in 20 years. For perspective, we're already almost 10 years into this Geni project. In other words, there is a tradeoff between growing the tree fast and keeping it 100% accurate. I think we are better off finding some path in the middle and being willing to temporarily sacrifice some accuracy for the sake of striving for faster near-completion of the tree - i.e. including all the living and deceased people in it. When the tree has all the people in it (which are finite in number, and we are probably more than 50% of the way there), then the inaccuracies and conflicts will gradually fix themselves over time.

That's the end of my thought stream. Been under the weather today and going to sleep now. I will hold off on any further merge work and watch this discussion.

-divon

Thanks for explaining what you're doing and how you see it, Divon. Thanks also for the vast amount of merge-in work you're doing.

We're trying to think through a solution to the Tree Conflicts that are left behind.
The problem with Tree Conflicts (as opposed to Data Conflicts) left behind is that they have the potential to create exponentially increasing bird's nests, that have the potential to destroy the tree's integrity if more trees are built into the errors. At the moment, you're merging in faster than we can identify the Tree Conflict errors, let alone fix them.

So, to my mind, there has to be a rhythm to this. Merge in > Sort Out > Merge in some more. To get that balance, perhaps we have to work together a bit better on this.

=When the tree has all the people in it (which are finite in number, and we are probably more than 50% of the way there)=
Explain this a bit more to me. Do you mean the SA tree? Is there another half again of incompleted / unmerged SA trees dangling outside of the world tree, as you've already merged in?

I'm also off to bed now - I've been wrangling with this all day, so I'll come back and chat some more about this tomorrow.