Friedrich Both, SV/PROG - Theunis Botha - Appel

Started by Johan Hugo Basson on Sunday, August 18, 2013
Problem with this page?

Participants:

Profiles Mentioned:

Related Projects:

Showing 91-120 of 146 posts

My view is the numbers are not clearly not definitive enough to be relied upon to ensure good merges...

They are an invention and therefore do not deserve to be part of your identity.

They should be moved to AKA, where they now become simply an aid to identifying a person.

Typo, should read : the numbers are clearly not definitive enough

Afrikaanssprekende ouens wat net soos ek nie goed is in engels nie lewer asb kommentaar in Afrikaans. Vir die wat nie kan verstaan nie stuur ons n Dictionary..... they just have to speak out.

Mooi so, Dries. Enige iets wat ons nie verstaan nie, sal ons google of jou vra.

Asb moet net nie vinnige (snel?) slang gebruik nie; dit is (dis?) die mooilekste om te versaan :-)

Private User & others:
how do you feel about the compromise of
1) using CORRECTED DVN numbers in the suffix (to TWO generations),
and locking them -
so that they aid merges; rather than causing mis-merges;

and
2) Keeping a record of the full DVN numbers in the aka; with a history of the changes in the About Me (for those who are prepared to maintain them)

Sorry for caps - not shouting, but using them to help show where my emphasis lies

In the case of a merge, one profile will have a CORRECTED DVN, while the other profile will have an UNCORRECTED DVN

The DVNs will be different - How does that help you in a merge?

thinking....

All other input welcome - and begged for - here..... :-)

Won't locking the Name field be enough to protect the corrected DVN in the suffix field?

Yes but not against the merges Don mentioned

... but that is an awful lot of locked profiles - I am hoping that the Curator note will be sufficient. We can only try

Yes I am still up far north and have a number of similar situations in my tree. Will try to post something tomorrow after scouting for more Zambian graves of South African relatives.

Locking a field doesn't do much more than stabilise the name -many international curators do ut as a standard practice on MP s

I don't really have an opinion but I can verify - I make MP, I lock name fields (except AKA which is always open).

This applies to every profile I MP now. Any curator can unlock / relock / update , on request & of course with source info submitted; curation is not affected.

When a field is locked in a merge conflicts "automatically" resolve to the locked value.

In other words it is easier to field lock than try for a detailed curator note, which does not show in tree view anyway. What does show is the "top" of the overview field, so that's where I repeat the correct relationships.

My issue with creating versions of DVNs in a profiles suffix name field, is just that, we are inventing genealogy.

The fact that we are struggling to decide on what to do in the Botha/Appel case speaks volumes: in that there is no published rules on how to apply the numbers in tricky cases...

My suggestion would be to take this opportunity to move this "primitive numbering system" to the AKA field.

The argument that they must be visible as they help to make correct merge decisions, seems to me, to be false.

One thing we've tried to do in the historic tree is keep the name fields "clean" of genealogical systems, and use "their actual name only" (normalized to contemporary spelling).

The display name & AKA fields are extra ordinarily useful for any other name that might be helpful.

I'm not thrilled with use of the suffix field for "systems" to be honest. There are legally appended suffixes in birth certificates for example, and honors such as O.B.E., knight, or even M.D. are the "common" usage.

So you might want to ask yourselves - is suffix a name? Part of a name?

I always had the requirement to show on Geni both the biological parents as well as the de facto/legal/official parents on the tree.
The way I treat those cases (not my invention - I copied it from a curator whose name I cant remember now.
In the Appel/Botha case, I would create duplicate profiles.
One would be under Ferdinandus Appel with his appropriate Appel DVN and surname Appel. A curator note on this profile referring to the duplicate profile. I do not add any spouses or children to this profile. This fix the blood line requirement. I would lock the the profile and maximal locking of fields.

The other profile I create under Friedrich Both with its appropriate documented DVN b1, not to upset the official accepted situation and not to invite continuous "correction efforts" .Here I also put a curator note referring to the duplicate profile. Here I put any spouses and children as officially recorded. This then reflects the official situation which seldom if ever will be changed by descendants. This profile I would also lock fields which I do not want to be changed except by suitably? authorised users.
The reason for the different last names for the profiles is to reflect the Biological as well as the official situation BUT ALSO to fend of professional mergers who would not see these profiles recorded as potential duplicates.
I have about half a dozen of these profiles in 9000 profiles, so I do not think it is qverly creating a "duplicates" load on Geni.
For those interested in the details, I could post links of examples.

On the subject of duplicating profiles, which I was a supporter of to deal with ambiguity on the tree - my experience when I tried it, is that it always creates continual daily maintenance and results in two higgeldy piggeldy half-half tree duplicates - especially in the high traffic areas of the Stam Vaders.
Justin Durand was the one who taught me this the hard way :-)
He will also be able to offer advice on the Adopted true vs DNA true GENi tree - as he has an interest in both (I don't know how he's resolved that).

Dries ek voel ook soos jy. Afrikaans. Sharon asseblief Google verkrag ons taal. Asseblief nie. Stuur liefs vir ons elkeen 'n skoolwoordeboek.☺

I vote for full de Villiers Pama numbers. Thanks

THanks, Pieter - We are not voting on the length of the numbers. I'll find that Discussion for you, but I desperately want to stay on topic here so we can come to a conclusion. Dankie man.

De Villiers numbers please.

Michelle we're not voting on whether to have them or not. THE DV Nos are here to stay. We are voting on WHERE to put them & whether to UPDATE THEM in the suffix field.

Please come and vote on the following in this Discussion:
http://www.geni.com/discussions/132812?msg=954617&p...

IN THE CASE OF De Villiers Pama Nos presently in the Suffix Field THAT CONTRADICT THE ACTUAL PROFILE POSITION ON THE TREE*
SHOULD WE:

1) Keep the FACTUALLY INCORRECT GISA DV NUMBERS IN THE SUFFIX FIELD?
(Ignoring the mis-merges this will create because it contradicts the Geni tree)

2) Remove the factually incorrect DV numbers to the aka/About, and PUT FACTUALLY CORRECTED DV NUMBERS IN THE SUFFIX FIELD, & lock the name/suffix field?
(Ignoring the fact that GISA hasn't got the resources to update them yet)

3) LEAVE THE DV NUMBERS OUT OF THE SUFFIX ALTOGETHER & PUT THEM IN THE AKA ONLY (& lock the Suffix Field to prevent them being added there.)

*(eg the DNA corrected BIOLOGICAL FATHER of Theunis Botha/Appel http://www.geni.com/discussions/127041?msg=954609 or THE CORRECTED SIBLING RANK ORDER of newly 'discovered' Stam Vader kids from slaves born in between their kids from White wives )

Voting closes Monday

I didn't respond sooner as I was away busy.

I think the question that we've been trying to drum up engagement in for the past 2 days is about whether or not we CORRECT DV numbers in the Suffix if they contradict the reality of their situation on our GENi tree?

Whatever we decide about where Theunis Botha (& his misattributed paternity) should be placed in the tree (under his biological or adoptive father) does not change the question of what we do if the number contradicts the reality on our tree.

Current Vote:

WHAT TO DO WHEN THE DV Nos CONTRADICT THE REALITY OF WHERE THE PROFILE IS ON THE GENI TREE & CAUSE MIS-MERGES:
Should we:

1) leave them = 0
2) update them = 3
3) remove them = 0

The above decision is pertinent to Theunis because we need to know the effect of placing him under his biological father on GENI (which was unaminously supported above) while contradicting this with a different DV no in the suffix..

The decision about biological vs adoptive fathers that Theunis' case stimulates will not affect the decision on http://www.geni.com/discussions/132812?msg=954674; but that decision will affect this Discussion.
Hence the need to get people's thoughts on that one first.

My vote would be for 1a and 2b.
Although I am generally in favour of correcting the the DVN's when more accurate findings show that the current DVN numbers were allocated based on inadequate research.
The Botha / Appel situation to me is a rather special case where I will keep him as a (b1) Botha linked to Friedrich Both as this was the official situation generally accepted by all and is reasonably sure that none of his descendants will alter this. I agree that his biological DVN should be quoted in AKA field and definitely in the suffix field of his duplicated Appel profile as per my suggestion above. I would also not change b2,b3 etc in the Botha line for the reason that those were also not allocated because of inadequate research.
If we feel strongly feel that we also change b1,b2, etc then we must bite the bullet and also accept that they were not even Friedrich Both's children but his brother's. And all these are not suddenly new discovery of our present day genealogists. It was already reported in 1926 in an article - it is only now that we have more sufficient proof via DNA.
I feel therefore that we should cast our votes for the general situation without considering the Botha/Appel case which in my view is a rather special situation clouded by various other considerations.

Okay, Thank you Daan. And the general situation is this:

When the tree is different from the DV nos, and we know the tree is correct, what shall we do with the DV numbers in the Suffix Field:

1) leave them = 0
2) update them = 3
3) remove them = 0

Please vote on this Discussion http://www.geni.com/discussions/132812?msg=954708 before Tuesday

In the specific situation of the Botha tree,
1)I have removed Theunis' DVN from the Suffix field while he is positioned under Ferdinandus Appel on the GENi tree (as per suggestions at the beginning of this discussion) because a Botha DVN Suffix will cause mismerges on the Appel tree.
Please comment

2) A decision then needs to be made about the other Botha children. If it is common knowledge that they are not Frierdrich's children, then they should have been placed under the acknowledged biological father.
Please comment

The specifics of this discussion, as I see it, is thus WHETHER WE WANT TO SHOW BIOLOGICAL OR ADOPTIVE PARENTS on the tree.

Perhaps this is a test cast pertinent to the world tree and we should start general Discussion to get people's thoughts on that on the world tree?

I agree with your closing comments re what type of tree we are building. Since it is a "family" tree, I suppose the adoptive one will always has preference since that is the de facto one.
On the other hand, so many people approached we to also help them finding their biological parents. The question is how do you document the situation. Certainly Geni cannot without full scale duplication, handle both situations.
The beauty of Geni is however that you are able to put the profile both under the biological parents with the correct DVN and under the adoption parents also with the "correct" de facto DVN as being done by GISA. This is the way I suggested that we treat Theunis Botha and Theunis Appel. This way it pose no problem for the Botha tree, but admit that it creates duplicate DVN's for the Appels. Since the de facto Appel trees does not "know" about him, one could leave out DVN in the suffix or regard him as b?c0. Pse just not tell me there were more than one of these in the de facto Appel tree!

Showing 91-120 of 146 posts

Create a free account or login to participate in this discussion