Catherine Tabourdeaux - Removing "SV/PROG" and "SM/PROG" from the suffix field name.

Private User, on the matter of duplication: South Africans are very parochial in their belief that we are the only area of the world tree at risk of same-name duplication: Old fashions in naming children after their parents and grandparents were not a peculiarly SA phenomenon, and occurred in many places in the world. (I'd hazard a guess that the British pool of names in that time period is as likely, if not more likely, to produce name duplication problems - eg the hundreds of John Browns or Mary Smiths. ) And when the 10+ DVNumbers appear on the profile in tree view they completely remove the view of the profile’s dates – which is what the rest of us use to tell if a profile is a duplicate of another one.

We receive many complaints about the DVNumbers in the Naming Fields (which include the suffix) - from non-SA users – not just morel.Within the SA tree, there are increasing errors (all that needs to happen is that one slave child that was left out in the 1600s has to be added into the b generation, and that entire surname line of thousands of numbers - down to every grandchild living today - becomes wrong,) and the incorrect numbers actually cause mis-merges. Also DNA testing is showing up more errors, like the recent one on the Appel/Botha line; or the sudden proliferation of Indonesian slave DNA markers in bewildered 'Old Cape Family' descendants.

Additionally, it can be a source of friction between SA users because many South Africans do not appreciate having the 10+ digits added into their grandparents' profile names without being asked. They do not see that it has any benefit at this level of the tree, & they – like Morel – object to the way it looks on their printouts. As many SA users do NOT use the DVNumbers as those who do, and nobody amongst the SA DVN users is willing to commit to keeping the millions of potential DVNumbers updated and correct to prevent them from creating mismerges.

It’s a really useful numbering system, I completely agree – especially at the level of the first generations of settlers, and when you’re reading down an indented list of patrilineal generations from one progenitor. I use it in projects – when I’m doing generational lists with links to profiles.
It’s useful info to have on the profile, if it exists, but whether it belongs in the Naming & Suffix fields is the question– and one which keeps coming up. If just the SV/Prog labels are upsetting morel, imagine how he’ll feel about the DVN on his descendants? He isn’t the only one.

A separate Suffix Box with the Preference to show or hide a set of options that included, for eg, Genealogy Numbers and DNA markers – might be a solution that works for everybody?

I would not remove it completely. I have come across profiles where I have had to move part of the name into the suffix as the person was not born with it. One example are Rabbinical titles. These are earned after birth and have nothing to do with their birth name.

Thank you Kevin Lawrence Hanit. Jan and myself are now trying to fix a mess in one family that are totally incorrect due to a merge and duplications.
The person obvouisly did not even look at the profiles and the daughter is now her prog/SV's daughter and wife, and also her mothers husband.
I am not at a place where I can undo everything but Jan is working with the sources.
Sorry to all my SWANEPOEL family, Private User - it involves Swanepoel once again.☺
Wishing you all a wonderful 2016 and hoping all "brickwalls" to be sorted out.

Sharon Doubell - on your above message: (www.geni.com/discussions/151986?msg=1061421 in response to my message: http://www.geni.com/discussions/151986?msg=1061169 )

I am in two minds as to whether you are in fact referencing to me or to other South Africans? Or to both? There is this old saying that half of us are xyz - which is a common theme for this message. Maybe I am half of the one and the other - theoretically and via love we all are? :) ... just your message may give out mixed signals... :)

Because you were part (and instigated) all previous discussions I could find on the South African Naming conventions and putting the use of DVN in question. I have gone through the history and here are those I could find - and at least one of these discussions link to even earlier discussions:

http://www.geni.com/discussions/145450?page=1

http://www.geni.com/discussions/137934?page=1

http://www.geni.com/discussions/132812?page=1

http://www.geni.com/discussions/137815

http://www.geni.com/discussions/138237?page=1

I don't expect anyone to read through all of this, but I have my own very short summary and the official summary below:

We agreed to use Suffixes per the official and collaborated RSA Naming conventions. We agreed that no suffixes will be 'long' - we agreed that in general two generations is enough (i.e. 4 digits). This is summarised too in the http://www.geni.com/projects/South-Africa-Profile-Conventions-Guide... under the use of Suffix field, with a link to an example.

Therefore I do not understand the 10+ digits argument in your message of yesterday - must be an oorsig for a lack of better word. The DVN should in most cases be 4 characters which is not long and enough to 'tie back' to your earlier ancestors as well as subsequently much easier to correct if required (i.e. if wrong)... in the long run the optimal solution.

Also, I am 110% convinced that the use of DVN reduce miss-mergers, and do not understand why you would say it would increases miss-mergers? Could you please explain your 'increase' argument in more detail before I make an oorsig? :)

If you (re-)read my message you would see that I specifically lobbied my support that Mr Morel's concerns be 'fixed' via the two avenues suggested. I hope we can find the solution here - and we have half the info as we do not know why the list view produces invalid data! Just want to work optimally - and I hope that any non-DVNers can be convinced eventually and that our (you, me, RSA, everyone!) collaboration efforts will be to the best interest of all.

Jan, this isn't a discussion about the DVN, and I was pointing out to you that it isn't a good idea to make it one, because not even all the South Africans are happy with it in the suffix.

10+ digits isn't an oversight. Your father and his father's profiles are examples - On tree view their dates are completely obscured by the digits.
I have explained above why the DVNumbers are becoming increasingly inaccurate and so cause mismerges.

Hmmm... :-/ I have not updated my paternal line to RSA standard, to prevent miss-mergers in future - GISA has not yet corrected my line in their records and therefore inconsistent DVNs. But thanks, this is but one example where one should have longer DVN in the suffix field - and why I defended longer DVNs in the discussions mentioned.

Will keep it short too (as I have done in all my posts, believe it or not!) but in the example Botha/Appel - it was decided that the Botha DVNs be updated in a discussion which you took part in (I almost listed that discussion too) - I was not part of that, but someone forgot to do it thoroughly perhaps or not soon enough? And even in that case, a person doing mergers on the tree (1) should have been made aware of the discussion, and (2) checked more relevant fields like DOB/POB and DOD and names and parents etc. Alarm bells should have gone off when more relevant fields did not match etc. This cannot be an example of DVN causing miss-mergers, not even in general.

Jan, we're talking at cross purposes here. This Discussion is about the use of SV/M PROG in the suffix.

As to the updating of the DVNumbers - as I said before - the users of the DVN won't commit to keeping them updated in the suffix - which isn't surprising as 1 change in the b line requires thousands of corrections on the tree.
If the Appel/Botha DVN have not been updated - surely that's a case in point?

To be clear - we are referring to the use of the Suffix field - where the candidates are SV/PROG...

In your post you mentioned - maybe then in response to my post - which was in response to earlier posts on the DVN (the candidate of the suffix field) - DVN... and cross-referenced this post to a separate DNA discussion, and DNA is also mentioned by some messages in this discussion and highlighted by you to go into a 'name field'. http://www.geni.com/discussions/151927?msg=1061410

The point is that one cannot isolate SV/Prog only, as highlighted by Bjorn too - someone mentioned the tip of the iceberg ;). One should have an idea of where SV Prog fits in, i.e. what are the consequences of a change, how does it impact the past, present and future. A small seemingly insignificant change can have large ramifications and create a new set of contradicting 'rules'.

Therefore I have to return to the DVN part, because, in the traditional sense, the first SV/PROG is actually "a1" in the DVN system. I think the full write-out is just 'dramatised' versions of the DVN, for clarity to GENI users. Therefore this discussion is actually the root of the DVN and therefore the focus should always be on DVN.

As to your claim that the users of DVN won't commit to keeping them updated, it does not make sense to me and I cannot call any requests for volunteers.. I am sure the users of the DVN are very much committed to keeping them updated, and that includes me :)

As to your claims that one line of b generation causing thousands of changes, also not true! :) Remember the RSA standard is 2 generations, I.e. there must be 1000 children in two generations for that to be true - and in the Botha/Appel case, I recall (maybe badly) there was only about 9 children (and not all where Appel) so it means each Appel child had +-100 children?

Returning to the DNA discussion - also part of the Suffix discussion as per original post, that will actually be a very long piece of text. It will only be useful to an individual if that individual actually has the same DNA (and even knows his DNA). Therefore it surely must not be displayed for all or per default, and therefore seems a very unlikely candidate for the Suffix field.

Time to let this go.

Can you please advise: I have not used the numbering system of which you talk. I have however used the suffix field for capturing my THW I -V greatgrandfather, great uncle V1 and cousins VII -IX as listed bellow. Is this this accepable or must it be changed? Or have I just lost the plot alltogether?

2nd cousin 1xr
Private

2nd cousin
THW VIII

Ist cousin 1xr
Private User

My great uncle
Thomas Howlett Warren, VI

My great grand fathers THW I -V
Thomas Howlett Warren V,b1c1

Thomas Howlett Warren, IV "Capt", b1 / LZL5-N1J

This would then be my SV/Prog
Thomas Howlett Warren III, SV/PROG / K69M-3YD

Thomas Howlett Warren, II / LXWZ-15Q

Thomas Howlett Warren, I / LXW8-9BJ

Sorry sharon, your post was not here, when I started my lost post, but appeared after Id posted it...

Eileen Winifred Warren II, your point is a good one - and relates to what June said before.

It's pretty frowned upon to use capital Roman Numerals because they are universally recognised as legitimate titles given to kings, but I don't know if acceptable alternatives exist.

As far as I can see, your "Settler" is a new SV/PROG profile, and should be attached to the SV/PROG project too. (From a quick look at the dates, there's a good chance he's also an 1820 Settler (a further project). but I haven't really looked carefully enough.

Alex Moes this pertains to a question you asked the other day. Yes, the SV/PROG is an Afrikaans/English double up. Many South Africans do not speak Afrikaans at all, and so found the Stam Vader/ Moeder abbreviations as puzzling as the rest of the world. We'd hoped the PROG translation would help English speaking South Africans feel included in SA genealogy too.

According to the book "History and Genealogy of the Warren family in Normandy, Great Britin and Ireland, FRance,Holldand Tuscancy, United States of America,etc A.D. 912 - 1902 by Rev Thomas Warren out family settled in 1840. I am still looking for the ship

I understand the settlers son was the captain of the ship but not yet found documention to prove or disprove this believe. The youngest daughter was born at sea 1840.

So should I use 1 - 9 as apposed to I - IX ?

At a glance I know THW 3 is the settler and THW 5 my great grandfather. "Place markers" of importance to me.

I don't know the answer to that. A discussion for the future, perhaps?

At a glance I know THW 3 is the settler and THW 5 my great grandfather. "Place markers" of importance to me.

If it helps at all - I think most of the genealogical work done in SA tree's work on DVN numbers.
I used Judith Susanna Hendrika 1 Stoltz, JSH 2 J v Rensburg, JSH 3 Marnewick, JSH 4 Marais, JSH 6 Meyer but that was a total mix up within a week or month.
Then I returned to the JSH a1b2c3 etc and ever since then - no mix up. As there are about more than one JSH J v Rensburg and JSH Marnewicks and in two instances two cousins married Nicolaas Marthinus Marnewick - cousins in the husbands side - non related but far away in the J v Rensburg side.
On my PAF they are marked automatically by the DVN system and never ever have they even showed as a duplication.
If this helps at all, why the South African researcher, and that is Afrikaans and English make use of DVN, I hope we can come to an argreement on this over talked about subject and clear the hugh messes in our tree, due to wrong merges.
I went away for 1 day and 1 night and when I put my PC on now, there are exactly 100+ messages of which only are about 6 not from Geni users, asking me to please look at a profile as a wrong merge took place.
And I am not always even a manager of all the profiles.
In my case it is frustrating and should be addressed as it starts at SV/PROG and goes straight down the tree.
Judi

Guys - let's not turn this into another interminable DVNumbers argument.

*The World Curators are asking why we're using the Suffix even for the SV/PROG.
*Mike has said he'd prefer we didn't use the suffix field even for the SV/PROG

We're trying to get around that.
It makes no sense to argue amongst ourselves about why some of you want to use it for the DVN too!

For what it's worth, I personally dislike anything in the suffix which has a reference number or name of any kind. A person's name should be the name they were known by when they lived. People who add profiles to trees and give you the reference number e.g. R3 or Page 19 make the tree look awful and the person like a laboratory animal. It is simply a jarring factor. You don't even know which tree they were referring to. Whenever I see an ancestor with such a number, I delete it. If a person is a progenitor then it's obvious. Anybody who moves to a new country and has children is a progenitor but we can't label the entire human migratory population as progenitors. I was shocked to see a comment that the South African progenitors are the forebears of apartheid. Perhaps the British politicians who murdered 40,000 Afrikaner women and children in the world's first concentration camps in the Boer War are the progenitors of Apartheid, as hate begets hate. Some of the greatest anti-apartheid heroes were .... Afrikaners. Geni is not a political forum and all persons, dead or alive, should be treated with respect. If the commentator looks back on the trees of South Africans, he will see in almost all cases that they are descended from Hottentots or slaves taken by the Dutch to the Cape. These, often with surnames like van de Kaap, are also progenitors of the leaders of Apartheid but also of their victims, many of them being distant cousins.

Private User - if one takes for example the common use of the Jr or Snr in the Suffix field, that distinguishes a father, grandfather or son, the DVN is exactly the same and it just does it so much better, being able to distinguish individuals over multiple generations. In that, it adds to the legitimacy of the tree and aids in eliminating duplicates - you ask/tell about "which tree" - the answer is that there is only One Tree (WFT) - on which we all work together.

Furthermore, another reason why the DVN is in the Suffix field, is to enable Geni users to view it in Tree View, or not - just have a look under your tree view options. It is important for people that are trying to correct / update the South African tree that it is displayed on tree view - moving it from the subject field will remove it from tree view and putting it in other fields will create further problems. Therefore this post too, as I believe it will truly mess up the South African tree if it is moved or deleted. I urge everyone in general = Please do not delete information - every bit of it is useful. Deleting any information is almost as bad as deleting a profile.

I will address one other issue you raised which interested me (I enjoyed your whole post as it mirrors my experience - but need to focus on genealogy), namely like the tree looks awful with markers and a person is treated like a "laboratory animal". I actually believe that is a rather good definition of Genealogy - one should be objective and keep emotion out of it. In that sense, as a factual exercise it is labelling people based on where they fit in the WFT.

Then all people are of course not treated as progenitors, but the DVN is used to trace an individual over many generations to all his progenitors. Have a look here: http://www.saintclair.org/numbers/numdvp.html on how it works. The RSA Naming convention is to have 2 generations on Geni and has been around since the start of the South African part in 2007.

I have explained in my earlier posts why this is a DVN discussion and no-one convincingly motivated why it is not.

Jan you are right - although this discussion started about SV/PPROGS etc, it includes any other similar additions in the Suffix field like DVNs, Eileen Warren's numbers or any others that are currently in the Suffix Field.

Yes, and the discussion is about alternative ways of of displaying those types of numbers/text fields in a separate searchable field if it should be outside the suffix field.

Although I do not agree to the difficulty of changing those numbers either in GISA documentation or in Geni if we follow the standard of 2 generations in the suffix field, it is a seperate discussion which does not add new perspectives on the problem here.
The discussion could be opened seperately or continued on the same topic some time ago, where the different viewpoints were clearly formulated and where the preference of SA users are reasonably obvious.

It's interesting, Daan, because I actually see the SV/PROG question as more analogous to the use of display name to highlight an important ancestor or historical figure.

Morel had brought up "Mayflower" passengers, the first arrivers to what became the USA. Isn't that more what a "PROG" is? The numbering system is a "different" issue in that case (although in the de Villers / Parma system, PROG = the a generation, if I have it right).

So. As example / analogy, the Mayflower Society identifies & assigns numbers to the 21 passengers surviving progeny, which is approximately about 20 million now. Not a numbering system that could be maintained in a suffix name field in Geni. In fact I'm not sure the MFS maintains numbers, either; although a number is used in their published descent books as part of their reporting.

However it "is" very important to Geni members to be able to quickly identify, visually, in search, and in match, the passengers of the Mayflower. Some of whom had full "legal" names with a usual suffix of Sr./ Jr. In other words, the suffix field is inappropriate when we know their name.

But the display name is needed. I hear the slippery slope argument & I don't agree, as I do think good taste & common sense will prevail, as usual.

Agree Erica.
What I wanted to get clear that SV/Prog is not the only text in the Suffix field in question. Many users also put the DVNs and other descriptors in that field and they would therefore be viewed just as "unacceptable" as any other descriptors which "are not supposed to be in the suffix field"
That is why Mike offered another field (as compromise?) in a previous discussion on DVN's

I think we're entirely on the same page, Daan. And I hope I've demonstrated ways that Geni developing a separate attribute field would be useful for all Geni users, although not always using the same key system.

But that needs now to be answered by software developers, as it's not as simple as doing it yourself on your desktop computer.

I'm wondering if we can return and wrap up the original question of SV/PROG? My suggestion being moving "that one designation" to the display name if not there already as can be done. And promises all around to maintain good taste & not overuse display name for attributes.

Erica, I read your posts above with interest - but I fail to catch one paragraph at all... what is the slippery slope argument? :)

I am fully against your wrap-up solution to using the SV/PROG in the display name - my alternative is to leave it in the Suffix field - as outlined by all my post above.

In the case of South Africa - yes the progenitors denoted by xxPROG, very much like the Mayflower passengers (well a bit more and in different ships and eras, there are 4500 on Geni - have a look by searching for the terms SV/PROG or SM/PROG on Geni!) - they were the grandparents of all of us here (agree - not all South Africans, but almost all Geni users from South Africa) and for these users I think it is satisfactory to be able to tie back to all these progenitors (6-11 generations back) as a reasonable obvious first aim - and entirely possible do to the good work done by many! (And much more easier using DVN)

But what we have is a new or even somewhat experienced user who has done some genealogy or paid someone even, or bought evidence from another website or society. And then without perfect knowledge of how the WFT works, starts to build his/her own duplicate "personalised" GENI tree.

Someone else then comes along and starts to add to that tree, and tie but one duplicate profile back to the WFT without realising that it actually a duplicate tree. Now the duplicate tree is green... and someone has to clean up.

I say this because I (and most others?) have spent more time eliminating these types of duplicates than what I have spent on anything else. It is not really adding anything - it is perhaps even better that the duplicate tree be eliminated as it should be much quicker. (but then there is perhaps new information added - usually towards the bottom - that must be incorporated)

If one removes but one SV/PROG without it being searchable or viewable in tree view (but not with Display Names - see my earlier posts - this is a personalised field), the number becomes inaccurate. Normally a duplicate tree will be started at the top South African progenitor, and now we have a problem. As I work in tree view mostly, I need that progenitor identifier there, and not as a display name. Using further Suffix identifiers like the DVN, it means that I don't have to set my settings to 9+ generations to 'know' that I have the right (non-duplicate) progenitor and therefore a clean tree - this is per profile (sometimes thousands!) - speeding up work rate.

A further alternative is that users should be made aware - hopefully the moment they join, and definitely as a report function "non-collaboration" - that Geni is not personalised, and a collaboration effort... even if it is your own direct family tree. Of course, the number of users and the level of accuracy, is not a zero sum game ;) BUT - the number of users to a profile is a function of the number of duplicates that were merged for that profile - which makes it clear that the SV/PROG progenitors are the profiles which are duplicated most - often in the 100+.. That is further argument that it should be left as is in Suffix field.

But we need to take it further - as where some see problems I just see solutions! As can be gathered I am very much interested in the design of numbering systems that could be useful without 'endangering' the stability of the WFT or what could lead to abuse. In the case of DVN, I am just taking what is for granted - not defending the use, but trying to convince those against such a notion, mainly in principle!

I would have thought a numbering system like the DVN is something the Geni programmers should have implemented a long time ago - and now they should jump at the solution and implementation thereof. One programmer mentioned that he can write automated scripts - well, why not write a script that adds birth and generation numbers to users? I will show what I have in mind in a separate discussion - but the solution I have in mind is useful for everyone that wants to tie back to progenitors like Mayflower passengers and other progenitors. It also clears up mistakes and formatting automatically ;).

Back to SV/PROG - moving it from Suffix (where I think it should go as in my previous posts) will (1) in the end give users licenses to create duplicate trees that will be difficult to spot, and 100 times more duplicates than what there is currently. It will be a nightmare to clean up one day soon. (2) give some anti-DVN communities licenses to remove DVN details from profiles (or also move it to display names), which will in the end make Geni a fictional story.

Keeping it in Suffixes (or a dedicated field displayed in tree view) is in my mind the long-term solution, when in future we will have AI and all other means to clean up mistakes - maybe duplicates too. But for now this has to be done with scripts, where it is much easier to do so with one on a single field than one where DVN is also added to another piece of text - and easily removed or changed without being picked up.

re: "As I work in tree view mostly, I need that progenitor identifier there, and not as a display name."

I see the display name in tree view. Do you have it turned off? Why?

Again maybe a South African thing, but my experience is that people complete Display Names with the information they want to see. For example, "Piet Pompies, Maria's Grandfather" - I.e. nicknames, badges or things that they were known for / famous quotes, army titles, or any other personally identifiable information.

That is not of use to me :( My default is off. Want to see birth names and dates :)

I only see that in very "near time" trees. For historical areas display name is used to source, same as professional names for celebrities etc.

Maybe should have added that our birth and death records here do not have names other than birth names (maybe referred to by others as given names) - and we need to source profiles (much better than currently)

"near time" - it is 'realistic' that near time for us must be up to the progenitor...