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

I agree that we should stay with the topic - get so irritated everytime when politics and apartheid are raked in with the long handle causing unnecessary emotions and differences

I can not remember that Mike Stangle's proposition for an alternative field to be created when we had our previous discussions about the De Villiers no's in the suffix field, has been shelved. I am in fact still awaiting such a field.

The fact is, that there is a requirement for grouping people together and if there is not such a field, users will tend to use the fields that are available. I take part in 2 other projects where we also use the suffix field to group profiles together. The suggestion to use a project for the grouping sounds feasible, but I have never managed to add living profiles to a project.

I also realise that if Mike make such another field available, it is just a matter of time before other users of that field will object. I might want to use it for SA progenitors, or Namibian progenitors, or unlinked profiles etc, then others want to use the same field on the same profile for a DNA designator or whatever. So I doubt whether it is possible to please everybody

Living people can be added to projects. In this example, there are 26 profiles, 20 of which are living people:

https://www.geni.com/projects/Cross-of-Valour-Canada/17978

Another examples, most of the profiles here are living people:

https://www.geni.com/projects/International-Football-Players-Soccer...

The point is: Name fields are for name-related data. The system breaks apart when we are trying to use name fields for "off-label" purposes, such as, inserting progenitor status data (e.g. "Fille du Roy", "Pioneer" or "SM/PROG"), or current event information (e.g. "Presidential Candidate") or historical event data (e.g. "Drown on the Titanic").

Geni offers:

1) pictures
2) documents
3) events
4) "About"
5) projects
6) curator notes

This is a solid toolbox. One would be hard pressed to give Mike Stangel a hard time for Geni being not good enough to group profiles together.

Once again: What is it that we cannot do with the above-mentioned tools? What is it that is so unique to South Africa progenitors that these six tools are lacking?

Why are we driven to misuse the name fields in a way that visually segregate profiles into one group, to the detriment of other Geni users?

Private User, I see that you have re-added the tags "SV/PROG" and "SM/PROG" to Charles and Catherine profiles. Their contribution to South Africa must be important.

It is also as important to reflect their contribution to France. I am hereof proposing to append the following label to their display name:

Charles Marais, SV/PROG, d'Hurepoix de l'Isle de France

Catherine Taboureaux, SM/PROG, d'Hurepoix de l'Isle de France

If you agree, I would be happy to apply the changes myself. Let me know.

Thoughtful discussion here, thanks everyone for bringing me up to speed. I did propose a separate key/value system for arbitrary data like the DVN, though I don't recall the discussion of using it for SV/PROG and SM/PROG -- I would have no objection to that but suspect it won't be displayed widely enough to satisfy the users who currently see these tags in the suffix fields all over the site.

I'm not opposed to leaving them in the suffix field, as they do provide useful genealogical information (misuse during apartheid aside), however I also agree in principle with Erica that these are not proper name elements and not really the same kind of animal as the proper suffixes like "Jr", etc.

Morel's solution (project, profile photo, bio) would be my preferred solution.

Second on my list would be to do this with the display name.

Third but still not totally out of the question as far as I'm concerned is to leave it in suffix.

If you want to do the 1st or 2nd option, we could probably write a script to find these suffixes and automatically add to project, add to bio, append to display name, etc.

Thanks Michael, I am in fact using the above except events on those applicable profiles. The requirement is to enter those designators so that they /the group are searchable. If searchable they could be placed in any other "Unobjectionable" field

The SV/PROG and SM/PROG suffix is just the top of the "problem", - all descendants has one as well.

It really is only a problem if we make it one!!

As Daan points out the image is not searchable and this information is valued by the descendants of these profiles. A searchable "reference field" which could be used for any reference on a profile would be a good solution. I don't see why it would be a problem if other tree users added information to that field (if it was there) that wasn't the DVN or PROG reference. I see many added reference numbers on the tree - usually appended to names which is far worse than using the suffix field.

I can just also mention this other problem - MEYER - for instance. I think quickly and it comes to about 10+ SV/PROG's.
When my husband and his cousin At started research on there SV and French forebearers (voorvaders), they eventually landed up with another MEYER from Beblenheim in France, Johan Georg MEYER., that was not at that time mentioned in the GISA registers. At contributed his world wide research.
My son, Marais Meyer went there when he met a friend from Beblenheim, while working in Geneva and that line is still there.

Mike Stangel can we revisit this option?:
=I did propose a separate key/value system for arbitrary data like the DVN, though I don't recall the discussion of using it for SV/PROG and SM/PROG -- I would have no objection to that but suspect it won't be displayed widely enough to satisfy the users who currently see these tags in the suffix fields all over the site.=

Another Suffix Field with 'non-name' options eg:
1.Genealogy Numbering:
2. DNA Numbering:
3.Other:
that could be a Preference to show or hide?

The problem with using the Display Name for the SV/M is the DVNumbers now in the suffix will be moved too - and we'll suddenly have hundreds of 10 digit DVNumbers on the Display Names of many SA profiles.
This doesn't solve the problem, as morel has already indicated; and from the pov of those of us who already find the error-prone DVN a pain in the butt :-), it's far worse to have them in the Display Name.

morel, can you explain what this means: =When compiling lists of people, the tags come up as invalid data=?
What programme is flagging them as invalid data? Not GEni. Are you saying it happens when you cut and paste names off Geni into another programme?

There are often times when I am working trees (not South African) where it would be extremely useful to add other tree numbering references - e.g. that used in Burkes etc. - to identify between people whose names are the same as the preceding 6 ancestors - a separate reference number field (as is available on most Genealogy software programs) would be invaluable.

I agree with Private User.

+1

Agreed!

Agree with June's point. A number reference for a grouping can be quite useful. Many family pedigree books assign a number, then can collate against the book easily.

Example of numbers in names - Alexander Williamson

June - your example is a legacy profile with inactive managers, I doubt it is a deliberate strategy for a Geni presentation; from the manager name its likely a collected GED file, uploaded in 2010, and the original Uploader is now deceased.

The example does point out how much cleanup we still need to do on the world family tree.

Madam Barn plz explain the advantage of numbering and how it acheive to get those number? i try to get an understanding but i cant figure out :/
Madam Howton Pedegree is AP?
all of those thing confuse me alot ..i use maiden name +AP to get a stronger and validate the genealogy if we wish a more complicated thing we just need the coat of arm of each family+ap+maiden+number+records

My point being that those numbers could be housed in a dedicated field - I appreciate it is inactive - just showing an example of the numerous files I find as I work - this in search of an Alexander Williamson Scottish distiller. Sorry I showed it now!! :-(

LOL. The problem is we don't know what the number refers to.

So there would need to be a label field also as well as the number itself.

Mike's query was that this "attribute field" might be smaller on the profile than people would prefer, I think the way a different language name field appears now? For me, that would be just the right size.

Also I think it needs to be spelled out that this field needs to be searchable, not just cosmetic.

Martin RhNegativ we don't have coats of arms in Canada & USA, do we ? :)

Here's an example I could use a number field on. He has at least 600 descendants listed in an external database, the daughters of the American Revolution; each of the Patriots are assigned an ancestor number

John Hart, Signer of the "Declaration of Independence"

So I would use the attribute field to add his DAR Ancestor number to the profile for a quick lookup

I think Mike's point is that the Suffix won't show on tree view, or when clicking on the parent names on an open profile.

At the moment the SV/SM suffixes are used by South Africans to be able to see quickly the outer limits of the SA tree. If you're looking for the progenitor profile who came to SA as the first settler, you can spot it easily without having to open each profile.

This is what Eileen Winifred Warren II is describing when she says =As there could be 6 brothers Marais who settled with their father, 5 would be my uncles where as 1 would be my gggggrandfather. I could therefore isolate the 6 brothers checking the path to find my grandfather as aposed to my great uncle. This makes finding a path a lot easier. =

Yes, thank you for describing that point. It is so easy to get lost in the tree, having visual clues for "key" profiles is a big help.

of course we got Coat of arm ,blason heraldique Madam Howton it was abolish but some family have keep the memory of the emblem

Not mine! :)

It saddens me that Alexander Williamson, which Erica describes as a "legacy" profile with no active managers which is in need of a clean up, has 35 approved SmartMatches. Someone, or several people, have taken the time and effort to approve those SmartMatches (well the few seconds to check the tick mark 35 times anyway) but not been bothered to do anything to tidy the profile.

:(

I am curious, although i doubt that it is an important point, why "SV/PROG" and "SM/PROG"? I understand what the letters stand for but is it not redundant to say someone is a stammvader and a progenitor, don't the two words mean the same thing? Is it just a Africaans/English double-up?

Thank you Sharon for this:

<At the moment the SV/SM suffixes are used by South Africans to be able to see quickly the outer limits of the SA tree.>

I have been patiently reading for two pages wondering what the useful purpose was :)

I don't work in tree view very often but as i recall it male profiles are blue, females pink, unknown genders are green and unknown people are grey. Surely it would be possible for Geni to introduce another colour into the palate (oranje?) which would make visual recognition simple even when zoomed out quite high on the tree where a text reference might be indecipherable?

I would envision it being a Curator only tool which other users could request in the same fashion that is done now with Master Profiles. It would not have to be limited to SVs or SMs but could highlight almost any fact, probably a Curator Note would be best on each profile to explain why that person is highlighted.

A slightly less intrusive approach could be to restrict the colour coding to just the frame around the profile image, MPs are purple.

morel writes :

"Living people can be added to projects. In this example, there are 26 profiles, 20 of which are living people:

https://www.geni.com/projects/Cross-of-Valour-Canada/17978

I only know of Mastering or marking deceased. Curious to hear if another method ?

Hope you all are enjoying a peaceful time. I saw this discussion today after a short break - need to add to it.

The original 'concern' raised is that the SV/xxxx comes out as 'invalid fields' when requesting Geni Lists. I have not experienced this myself, but if true, I do not understand why. I can only think it is because of the use of the "/" (programming?) - so the easy solution maybe just to write SVxxxx and SMxxxx - cannot see a problem as the "/" is redundant in any case. All suffixes are text formatted - examples on Geni Naming Convention are "Chief", "Uba", region, etc.? PROG definitely seems to be Suffix field orientated, but see suggestions below :)

That way only about 4500 South African profiles need to be updated - and the few projects related to the use thereof. Should maybe add RSA in there too, while we are at it! One mentioned SAFProg for a French prog, but I believe the reason for the M and the V is to distinguish per gender while surname passed to children based on the father's surname. SAMProg and SAFProg ?? Currently the country of origin is managed by specific RSA projects for French, Netherlands, etc. progenators but not directly via a specific denotation.

I see that the SM/PROG has been removed from this Catherine Tabourdeaux's Suffix - but it still comes up when searching with the SM/PROG - good. But yes, it creates issues as outlined below:

The original post contains a link to Geni Naming Conventions, and there are 9 references to the use of the Suffix field on that page. None of that is conclusive, and even the use is different based on time and area. My firm believe however that the use of Progenator should be in the Suffix field, not in any names or Display name fields. The reason is that one should(?) work in the Tree View - debatable, but you need to consider as much information as possible in a single view - and for me I cannot work with Display names there (which is commonly used as 'personalisation' by MANY people with more in-depth knowledge of specific profiles etc.). I religously do include Suffixes in Tree View when viewing South African profiles - as it is easier to 'trace' ancestor lines specifically using the South African DVN conventions. (bottom line: South African names and surnames are limited and without DVNs we would be lost in tracing South African ancestry - I do not know how to explain it otherwise without going into details).

A separate issue, mentioned, is that of duplication. A serious risk in South Africa. One way to reduce duplication considerably, and how I personally experience it, is if I spot a South African tree (in tree view) that does not contain the SVPROG (and other DVN info etc) as the head of the tree when viewed with Suffixes on. Now without that in the Suffix, one has to physically click on that profile which is a time and bandwidth waste and unlikely to be done... I just find that people with no knowledge of DVNs are more likely to create duplicates - which btw are also harder to spot due to incorrect and incomplete information. Also, there is just no easier way because the borders will be green whenever a profile is linked in ANY way to the Big Tree.

So in my opinion not using the Suffix field for DVN numbers in South Africa would mess with the South African tree. I suggest rather the Geni list view with invalid data should be fixed - ie remove '/' or just fix the list view problem. I further suggest that a South African section is added to the Geni Naming Conventions page - or a link to the South African naming conventions page (to remove duplication :) ) South African conventions are to use the Suffix field for DVNs and has been since the start and removing would destroy a decade of work by many.

On one solution mentioned: It is unrealistic to remove DVN Suffixes and add them to other fields, specifically in the Curator block. I mentioned the 4500 current SV/SM progenator tagged fields above, but the use of the DVN in the Suffix stretches to tens of millions (potentially, currently millions) of South African profiles. I do not see how all profiles can realistically be MPed and re-DVN'ed per hand.

Daan has mentioned the earlier discussions and for clarity those should also be linked to here.

I agree with those hinting that using a DVN method could benefit many countries with prog's - although the task is daunting, I would rather believe that the South African way should be the example rather than the exception.