Add something for Dutch "Roepnaam" (CALLNAME)

[mother10]

As explained here: https://www.webtrees.net/index.php/forum/2-open-discussion/37395-gedcom-7-personal-name-structure by JustCarmen, Dutch people have trouble entering "Roepnaam". That certainly is not a Nickname, but indeed a "Callname", so a name by which someone is known, is called so to speak in daily life.

I think "Roepnaam" is only used in the Netherlands, but I am not sure of that.

As stated in that link, and I will use myself as example now, at birth I was given the Firstnames "Catharina, Johanna, Elisabeth", and together with that my parents gave me the "Roepnaam": "Tineke". So everyone knows me as Tineke and those 3 "Firstnames" are only used on official records.

So GIVN is "Catharina, Johanna, Elisabeth", NOT Tineke. But Tineke is NOT my Nickname, my Nickname is Mother10.

As JustCarmen said in that link, maybe there should be a CALL for these cases.

Or maybe another NameType. In that case it might be possible to have that in the same minor as the other NameTypes.

Hope I made myself clear.

[Norwegian-Sardines]

Your nickname is not Mother10. In IT we call that either a username, a sign-on name or a screen name.

That being said, I understand that Roepnaam translates differently in Dutch, however, it is closer to a nickname (we also sometimes use the term “call name” as a substitute for nickname) as used in the American English language than a name with numbers and non-alphabet letters. Therefore, maybe the definition of nickname needs additional wording to help include the concept of Roepnaam, and discourage the use as a computer/application IT term!

Maybe you can help (along with JustCarmen) in our GitHub name thread to a more common understanding of terms!

[Norwegian-Sardines]

Because of internationalization, the same word has different meanings depending on local use. For example: Biscuit is different in the US vs UK. US has no idea what driving a lorry is, or that a car has a bonnet. Terms like these need definitions when communicating. Therefore, nickname may need to have a definition that includes the word “call name”, or “familiar name”. My pedigree dog has a full given name, but also a “call name”. ( NOTE: I’m not making fun of anyone or disrespecting anyone with that statement).

[mother10]

Hi Norwegian-sardines (really like that name ;) ) Dont know what you mean by "Namethread", but if I had to define callname (roepnaam) I would say:

A callname (roepnaam) is the name your parents gave you at birth, that is to be used in daily life, in stead of your official firstname(s). Callname you only get once at birth, and you only have 1 callname (roepnaam) During life you introduce yourself to people with your callname (roepnaam) followed by your lastname. You never introduce yourself with your official firstnames. Other people address you directly with your callname (roepnaam)

A nickname is a name you get during your life by other people (including your parents), and you can have more nicknames. You normally dont use your nickname yourself, it is used by other people, mostly when they speak about you, not when they directly address you.

When i named my kids I gave them more firstnames, and I made sure their first firstname was also their callname (roepnaam). So my kids have their callname (roepnaam) officially registered as a first firstname. But that might be an exeption.

Hope I made myself clear that roepnaam is not part of nickname.

About your dog, no I dont mind you used that example ;) your dog can have a callname AND a nickname AND those official names on his pedigree document.

And yes, my nickname IS Mother10, that started way back in 1971 at my first programmer/developer job for the Dutch Royal Navy in Den Helder. See here: https://www.motherware.com/info/mtw-about-me.php and here: https://www.motherware.com/info/mtw-about-motherware.php (Notice the domainname?? :) :) )

So in those days there were no "logins" or "usernames" or whatever, :) there was nothing, we had to invent everything ourselves.

"Those were the days....." :) :)

(yes I am an oldy......)

[Norwegian-Sardines]

Then this is like the German Rufname! Which we have also discussed! https://github.com/fisharebest/gedcom-name/blob/main/call-names.md

[mother10]

Yes indeed. I try to find all discussions but its difficult. I also added an idea about Name.Date, but no answer to that yet. In the link i started with i saw more asking for a DATE in a NAME. Will that be discussed more?

[dthaler]

"Call name" / Rufname is currently discussed in the Technical FAQ at https://gedcom.io/techfaqs/#how-do-i-record-a-preferred-name-among-given-names.

[albertemmerich]

Roepnaam and Rufname are similar, but not the same. Rufname MUST be one of the given names, as it is that one which is underlined in official German documents. Mother10 is showing that the Roepnaam "Tineke" is NOT one of the given names. So both are special versions of naming people, however different. They need different GEDCOM structures!

[Norwegian-Sardines]

Roepnaam and Rufname are similar, but not the same. Rufname MUST be one of the given names, as it is that one which is underlined in official German documents. Mother10 is showing that the Roepnaam "Tineke" is NOT one of the given names. So both are special versions of naming people, however different. They need different GEDCOM structures!

I disagree that they need different GEDCOM structures! Adding on a new structure for every variation of how names are used/assigned by different cultures, customs and time period would make the NAME tag cumbersome and impossible to use and support. A better solution that does not include a new structure for each naming variation must be developed!

One solution could be to create a singular tag (call name, familiar name, ?) with an enumerated TYPE where many of the more well used types of alternate names (nickname, Roepnaam, Rufname, preferred name, other) can be selected, with an option to incorporate a new one. No-one here is an expert in all naming customs, any changes must incorporate input from individuals from Asian, Middle-Eastern, African, Native American and other cultures to be sure we don’t go off the deep-end creating overly complex structures that support limited use while leaving out other aspects similar to these entries.

[Norwegian-Sardines]

By the way, in Norway the Rufname equivalent is “kallenavn”.

[Norwegian-Sardines]

"Call name" / Rufname is currently discussed in the Technical FAQ at https://gedcom.io/techfaqs/#how-do-i-record-a-preferred-name-among-given-names.

In the software I use (with a large international user community) we suggest and support “preferred name” as follows:

1 NAME Johann Magnus* /Olsen/

Where the preferred name is followed by an asterisk.

Rufname could be supported this way rather than using Multiple NAME tags or a custom tag!

Using a asterisk was the common way to denote preferred name back in the days when most everyone did their genealogy research using paper/cards and was the way I was taught to do it before everyone had a personal computer!

[tychonievich]

Discussed in steering committee 30 MAY 2024

• Rufname (and kallenavn?) is a name part, a property to add to a GIVN and suggests an extension to the name parts or a new substructure of GIVN.
• Roepnaam is a separate name, suggesting a new NAME.TYPE.
• Both are given at birth, where nicknames are generally given later.
• Both are sometimes translated into English as "call name," as are some other ideas like login names, military handles, etc.
• We should update the technical FAQ to address the roepnaam case, and consider this in future additions in 7.1.

[Norwegian-Sardines]

Will this new NAME.part be called “call name”? If it is called Rufname, I would strongly disagree! Another option would be “preferred name”. Again giving it a name that is leaning toward the German only name is too restrictive and in my opinion WRONG.

[tychonievich]

I'm fine with a different name for these structures. I don't like "call name" for them, though, because that term is so heavily overloaded, encompassing at least username, nickname, professional name, preferred name, not-yet-official name change, as well as rufname and roepnaam.

I'm not expert on these topics, but I've yet to find a non-German parallel to rufname or a non-dutch parallel to roepnaam, and don't understand either to be synonymous with kallenavn. My current understanding of these three concepts is this:

• In German birth records, one given name is highlighted as the name someone is called, the "Rufname". This seems to me to be a distinct subtype of the name part GIVN.
• In Dutch birth records, two names are listed: one legal and one for daily use, the latter being the "Roepnaam". This seems to me to be a distinct subtype of the name type BIRTH.
• I'd not heard of "Kallenavn" before your comment above, @Norwegian-Sardines, but reading a translation of https://nn.wikipedia.org/wiki/Kallenamn they appear to be what in English we call nicknames: informal names in daily use, but not on birth (or generally any other official) records. Do I understand that correctly? If so, it seems to me to be equivalent to the existing NICK structure.

[Norwegian-Sardines]

but reading a translation of https://nn.wikipedia.org/wiki/Kallenamn they appear to be what in English we call nicknames: informal names in daily use, but not on birth (or generally any other official) records. Do I understand that correctly?

The wiki does not follow the understanding I have for its use in Norway names from 100 years ago! Remembering that in upper class Norway from times of and before the Hanseatic League, names in Norway and many German influenced places had similar naming customs.

Here is the logic used by the Germans for Rufname. It is a name that is part of but not the first name in the official birth name. It is highlighted and used in the future as the individual’s official name. This name is NOT a nickname.

By your reading in Wikipedia it is interpreted that Kallenamn is just a nickname, but you indicated that nicknames are generally added after birth and informal names in daily use!

I have multiple members of my family both in historic use and present day where they have multiple given names but officially use in documents their 2nd (sometimes 3rd) name. These are NOT nicknames, by similar logic as the Germans. I’ve known these names to be the “preferred name” in all legal documents. For example: My great-grandfather was named Ludvig Magnus and he was officially know from birth by all member of his family, the town and the firm he owned as Magnus. Why? Because every first born male was name Ludvig for generations (if the first born male died as a youth a male born after his death may be called Ludvig also) and their were certainly multiple cousins named Ludvig, but each was given a unique 2nd name and called that throughout their life, NOT a nickname!

The trouble I have here is that these names are not called “nicknames” so the NICK tag is out, and if Rufname becomes a component of NAME I could not enter it in that tag as well because it is not that either. I can’t enter a different NAME.TYPE as suggested for Roepnaam because the name is already in the primary name tag.

This is why I strongly suggest that Rufname as an independent value as a subset of GIVN is not correct for my needs. And this is why we implemented an asterisk following the preferred name in the NAME tag in our software. On display it gets underlined.

[mother10]

• In Dutch birth records, two names are listed: one legal and one for daily use, the latter being the "Roepnaam". This seems to me to be a distinct subtype of the name type BIRTH.

In Dutch birth records ONLY the official names are listed. The roepnaam is given by the parents at BIRT, but only mentioned on the birthday card (or newspaper announcement and such), NOT in the official records. Maybe you got confused because I wrote I put the roepnaam in the official records too. But thats not common. It was only my doing because it was the only way I could have roepnaam officially recorded. But indeed in my opinion roepnaam DOES belong to BIRT.

[mother10]

I was just thinking: Maybe a term like DAILYNAME would work? Can be used for roepnaam, maybe also for rufname and such?

[Norwegian-Sardines]

In Dutch birth records ONLY the official names are listed. The roepnaam is given by the parents at BIRT, but only mentioned on the birthday card (or newspaper announcement and such), NOT in the official records. Maybe you got confused because I wrote I put the roepnaam in the official records too. But thats not common. It was only my doing because it was the only way I could have roepnaam officially recorded. But indeed in my opinion roepnaam DOES belong to BIRT.

If the Roepnaam is not an official name in birth documents but introduced later, by the logic of others, it is a nickname! However, personally I would not use the nickname tag I would create a second NAME entry and use the NAME.TYPE and set it to “aka”.

one of the major issues forgotten in this thread is that not all software even support the NAME subtags, so if it’s not in the NAME tag these subtags are dropped. So I usually suggest using multiple NAME tags and a TYPE of “aka”.

[mother10]

The roepnaam is introduced at birth! Always! (parents have that name ready before birth, together with the official names) Even if it is not listed in birt documents it is always listed on the birthday card that is send. It is most always a form of one of the official names, and thats done because those official names were really long names sometimes and you dont want to bother a little child with a very difficult long name. So roepnaam is a shorter form of that. It is used from the moment of birth. It is never a funny name like nickname can be. So i disagree by saying roepnaam should be nickname.

[albertemmerich]

GEDCOM-L had decided to use with GEDCOM 5.5.1

1 NAME Albert Wilhelm /Emmerich/
2 GIVN Albert Wilhelm
2 _RUFNAME Albert
2 SURN Emmerich

The payload of _RUFNAME must be one of the given names. We discussed the possibility to mark the Rufname by _Albert or by any other marking character, but decided to use the extension tag _RUFNAME. As GEDCOM 7.0 has not yet implemented new NAME structures (there is a group working on that), the programs in GEDCOM-L group stay with the extension tag _RUFNAME. A later version of GEDCOM spec will have a solution for this.

[albertemmerich]

Roepnaam is a second name of a person, it is not an official name, but the person is known by this name. My solution for this would be:

1 NAME Catharina Johanna Elisabeth /Xxx/
2 GIVN Catharina Johanna Elisabeth
2 SURN Xxx
2 TYPE BIRTH
1 NAME Tineke /Xxx/
2 GIVN Tineke
2 SURN Xxx
2 TYPE OTHER
3 PHRASE Roepnaam

[fisharebest]

My solution for this would be:

Doesn't this imply that Roepnaam applies to Tineke /Xxx/, when it only applies to Tineke

@mother10 - how would roepnaam be used/displayed in a genealogy application? For example, in a context where only one name can be displayed such as a page title or a box in a chart?

[mother10]

My solution for this would be:

Doesn't this imply that Roepnaam applies to Tineke /Xxx/, when it only applies to Tineke

Dont know if I fully understand this, but i would say roepnaam only applies to Tineke. Not to xxx, xxx thats my lastname. So maybe it should be:

1 NAME Catharina Johanna Elisabeth /Xxx/ 2 GIVN Catharina Johanna Elisabeth 2 SURN Xxx 2 TYPE BIRTH 1 NAME Tineke 2 GIVN Tineke 2 TYPE DAILYNAME

@mother10 - how would roepnaam be used/displayed in a genealogy application? For example, in a context where only one name can be displayed such as a page title or a box in a chart?

Do not fully understand this either. Sofar I cannot enter roepnaam (or DAILYNAME) in any way.

When I fantasize I should say it should display:

Tineke xxx So the DAILYNAME followed by the lastname.

In a previous post I introduced DAILYNAME because that might better define what it is. Its the name thats used in daily conversations written and spoken. (when friends and non-official people write me emails and such. When people meet me they say "Hi Tineke" also.) When I sign an email or a non official paper, I also use Tineke xxx.

Thats why I thought DAILYNAME might be better. Rufname is, as far as I understood, also a daily name.

You could even define as follows in case you want the "official names" to be used in reports and such::

1 NAME Elisabeth Catharina /Xxx/ 2 GIVN Elisabeth Catharina 2 SURN Xxx 2 TYPE BIRTH 1 NAME Elisabeth Catharina 2 GIVN Elisabeth Catharina 2 TYPE DAILYNAME

Now in fact you redefine the official fistnames, also to be seen as the daily name.

If thats too complicated, you could instead define gedcom: If there is no daily name use GIVN plus SURN in the reports and titles. If there IS a Dailyname defined, use dailyname and SURN in titles and reports

[fisharebest]

@mother10 - how would roepnaam be used/displayed in a genealogy application? For example, in a context where only one name can be displayed such as a page title or a box in a chart?

Do not fully understand this either.

In charts, there is usually room to display only one name. e.g.

In such a chart, would you expect to see your official given names, your roepnaam, (or both??)

[mother10]

@fisharebest I think i just added that

[Norwegian-Sardines]

GEDCOM-L had decided to use with GEDCOM 5.5.1

1 NAME Albert Wilhelm /Emmerich/
2 GIVN Albert Wilhelm
2 _RUFNAME Albert
2 SURN Emmerich

The payload of _RUFNAME must be one of the given names. We discussed the possibility to mark the Rufname by _Albert or by any other marking character, but decided to use the extension tag _RUFNAME. As GEDCOM 7.0 has not yet implemented new NAME structures (there is a group working on that), the programs in GEDCOM-L group stay with the extension tag _RUFNAME. A later version of GEDCOM spec will have a solution for this.

I participate in the “working group” and this is why I’m trying to understand why Rufname needs special consideration when I have similar needs in Norwegian Genealogy and USA based Swedish/Norwegian descendants, can’t use Rufname because that is German only, and am very happy to just use the term “preferred name” (DailyName?) and can indicate this with an asterisk after the name!

[Norwegian-Sardines]

As I indicated before and @fisharebest kind of touch on, display names and many software applications only use the NAME tag and either drop completely or don’t use alternate names or the NAME subtags when displaying a name. Having the ability to display “preferred names” and nicknames (two separate categories of name) from the NAME tag is important. If the German use, and addition of, _Rufname as a subtag is implement internationally, it still will not be displayed in some mainstream software due to the fact they ignore all NAME subtags.

[tychonievich]

Thanks for the clarifications, @Norwegian-Sardines and @mother10.

Is rufname the same idea that GEDCOM-X calls "primary"?

A designation for the name of most prominent in importance among the names of that type (e.g., the primary given name).

(As an aside, GEDCOM-X also uses this same name part qualifier for the primary surname for cultures like Spain that have have multiple surnames.)

That German documents has primary names on the official birth record is not true in most places I've done research, but the idea of a primary name part identified at birth is common in many cultures (for example, I have 2 given names but the first was chosen by my parents as my primary given name; my father has 2 given names but the second was chosen by his parents as primary given name). I've also found it implicit in some other sources where e.g. the first reference is to "Thomas Alva Edison" but subsequent references are just to "Thomas Edison," implying "Thomas" is primary.

I agree with @albertemmerich and @mother10 that roepnaam is a separate concept and a separate NAME, not just a part of an existing name. @mother10, I'm open to dailyname as a name for it; but before committing to that want to understand when each name is used a bit more. Is it only used for friends and other people you are close to? Would you use the familiar name of a boss, of a co-worker, of a business counterpart from a different company, as a pen name, when running for office, ....?

Which of these seems most correct?

roepnaam	non-roepnaam	notes
no TYPE or TYPE DAILYUSE	TYPE LEGAL or TYPE OFFICIAL	if roepnaams are used except in special situations
TYPE INFORMAL or TYPE FAMILIAR	TYPE FORMAL	if roepnaams are used with casual but not formal forms of address
TYPE FAMILAIR	no TYPE	if roepnaams are used with friends but not the public

(I'm not proposing those as the final draft, just trying to understand the usage better)

[Norwegian-Sardines]

@mother10 I’m a little confused as well with the “Hi Teneke” greeting. To my ear, this name would not be used to sign a legal document, but is more of an informal name used in familiar circles.
My aunt Dagny Muriel Simonsen was given the name at birth of Deda and was called that in Norwegian circles, later it was “Americanized” to Dee.
I consider both of these to be nicknames (we don’t have a different term for it), but I enter them both as “aka” names because they were “also know as” those names and the name can be indexed in software better as a separate NAME tag rather than using the NICK subtag.

[mother10]

In very official situations I would only introduce myself with a lastname, except when the person I meet also gives his/her Dailyname. So when I would apply for a job and talk to a director or such, and he would give his lastname only, I will give my lastname only. When that person gives his dailyname AND his lastname I do the same. In those cases we never give our official firstnames, those firstnames are really a "paperwork" thing.

In less official cases, new people but sofar unknown to me, I would give my dailyname and lastname. I only use my official name(s) when I have to fill in forms and the form has a field that says: "Firstname(s)", then I use Catharina Johanna Elisabeth. Those mostly are very official forms like insurances, taxforms and such.

Very often forms also have a field called roepnaam and I fill in Tineke there. Those are less official forms.

If a form only has a field roepnaam and no field Firstnames, I fill in Tineke, not my firstnames. If forms have no field roepnaam, I leave Tineke out and just add the official firstnames.

So I think it is something like: (sorry dont know how to create a table here ;( )

--roepnaam--------------Firstname(s) --DAILYNAME--------------GIVN -Type dailyuse-----------type official/legal

Hope this is clear enough, if not please ask.

[Norwegian-Sardines]

@tychonievich

Why are we differentiating terms like “aka” vs “nick name” vs “daily name”. These all can be used interchangeably by different people and cultures. Nick names don’t have to be “funny” they are just another way to identify a person just like “aka” or “daily name”. I could also throw in other types of names like; stage name, and nom de plume. If I search the internet I couple probably find culturally varied names that people know by alternatively.

[mother10]

@mother10 I’m a little confused as well with the “Hi Teneke” greeting. To my ear, this name would not be used to sign a legal document, but is more of an informal name used in familiar circles.

"Hi Tineke" will be used by people who know me, and whom I have told my DAILYNAME. That can be friends but also colleagues, so certainly not only in family circles.

Hope this is more clearly?

[mother10]

Ok here something not from me but from such a chatbot. I asked the thing about the dutch bijnaam and roepnaam and asked for arguments. This is what I got, and to me this seems a perfect explanation. (yes its a silly bot but sometimes they might be usefull :) :) )

==bot start == Yes, you are correct. In English, "nickname" indeed means something different than "roepnaam" in Dutch. Here are the differences and arguments:

Nickname:

1. Definition: A "nickname" is an informal, often humorous or affectionate name given to someone. It can be based on personal characteristics, behavior, or a shortening of their real name.
2. Usage: It is usually used by friends or family and can range from something given out of affection to something used playfully.
3. Examples: "Bobby" for Robert, "Shorty" for someone who is short, or "Doc" for a doctor.

Roepnaam:

1. Definition: A "roepnaam" is the name someone prefers to be called by or the name they use daily, often a shortened or variant form of their official first name.
2. Usage: It is used in both informal and formal contexts, and is often a practical name that is easier for daily use.
3. Examples: "Jan" for Johannes, "Annie" for Anna, or "Kees" for Cornelis.

Arguments for the Difference:

1. Context and Usage:

   • A nickname is often used in a playful or informal context and can also be temporary.
   • A roepnaam is used daily and in various contexts, both formal and informal, and is usually permanent.

2. Source and Meaning:

   • A nickname can come from various sources of inspiration, such as physical characteristics, personality traits, or events.
   • A roepnaam is usually a shortened or modified version of the official name, chosen for convenience or personal preference.

3. Perception and Formal Use:

   • A nickname is often seen as less formal and more playful.
   • A roepnaam is generally considered acceptable in formal settings, such as at work or in official documents.

Conclusion:

In Dutch, "bijnaam" is a good translation for "nickname," while "roepnaam" has a different meaning. It is important not to confuse these two terms to avoid misunderstanding, especially in contexts where formal and informal naming conventions play a role.

== Bot end ==

[Norwegian-Sardines]

Based on the above, the name used in my family since I was a child is “Kenny”, I prefer to be called “Ken”, but my legal name is “Kenneth”. I would call the shortened names “nicknames”, but if I lived in the Netherlands they would be my Roepnaam, but I would never pick that because I don’t live there!

The example given seam out of touch!

Now we have data inconsistency in usage and potentially how these names are displayed in reports, charts and web screens!

[tychonievich]

@Norwegian-Sardines asked

Why are we differentiating terms like “aka” vs “nick name” vs “daily name”.

I wasn't a driving force in the names discussion when drafting 7.0.0, but as best I recall the conversation went like this:

• We started drafting a revamped name system, but we're not sure what it should look like and want to ensure we can convert 5.5.1 to 7.0 automatically, which limits how much we can do there; we ended up postponing that to a future version.
• We kept all name parts that 5.5.1 had.
• We added AKA because we knew of several applications that misused the ALIA tag for that purpose (this was even called out in the 5.5.1 spec as something people do), and knew that those applications used it as distinct from NICK.
• I don't remember why we added MARRIED, MAIDEN, or PROFESSIONAL.
• We discussed adding RUFNAME but didn't; I recall a digression about whether it should be a substucture of GIVN or a separate structure and whether the same name should have both GIVN and RUFNAME or not, but I can't recall any rason why that would have stalled RUFNAME when it didn't stall MARRIED.

In my opinion the current NAME situation it messy and worth replacing, part of why I was in favor of forming the names working group. I hope we add at least new recommendations, possibly new structures and some deprecation of redundant structures, in 7.1; and possibly a new system in 8.0.

I will note that naming a tag RUFNAME will not prevent it from being used in other cultures unless its defining text is very specific. We already have, e.g., IDNO used for more than just numbers, NATI used for more than just nationalities, etc. But I'm open to calling it PRIMARY or something else.

@mother10 thanks so much for the extra detail! This reminds me of how christian names were used in at least 19020s American Catholic culture (the only place I've seen them in my own research, though I know they go beyond that): not the legal name, but then name you use day-to-day and on some documents, assigned near or at birth.

[Norwegian-Sardines]

@tychonievich

In my opinion the current NAME situation it messy and worth replacing, part of why I was in favor of forming the names working group. I hope we add at least new recommendations, possibly new structures and some deprecation of redundant structures, in 7.1; and possibly a new system in 8.0.

I totally agree and why I joined the group. The problem I see is that like the v5.5.1 to v7 “we can’t do that” attitude, we will have that again. We need better understanding of international uses and naming conventions, not just closed loop “I’m not changing my terms to fit more generic use and design” attitude!

[mother10]

Hello all,

When following this discussion, and reading about situations that do not or will not fit in the currenct Gedcom specs, I wanted to think things over. Sometimes you have to start looking at things from a new point of view. From my early days as a programmer/developer for the Dutch Royal Navy, way back around 1972, we had a saying: "Start looking at it with a different cap on your head" (Navy guys wear caps, depending on their rank) So thats what I tried here.

What I saw here was that more and more NAMEtypes were added, which might make things more complicated then it should be. Thats no reproach, in fact i did the same thing, by starting this discussion.

In those early days I spoke about, when there were no books or standards, we had to invent things ourselves. We had to program a system, with which you could stear a ship, operate its army, interpret radar data, and much more, all inside 64K of memory with a wordsize (dont laugh) of 24 bits. (where everyone else used words of 32 bits.) We did have a "high level" compiler (JOVIAL) and used lots of machinelanguage to make things fit. But because of all that we learned that "declaring data is half of the work". Which means that if you can put a lot of logic inside your data, the program needed is easy and maintainable.

So ever since, whatever problem I look at, I try to "Make a drawing". If I can do that, the solution and the program needed might be clear. Gedcom looks like building blocks, so I try to keep that in the back of my head. The simpler and the more universal those blocks, the better. As soon as things become really complicated, it might mean there maybe is a more simple solution needed.

Now my reasoning might not be completely right, and I dont pretend I succeeded with what I just wrote, but I wanted to give it a try and maybe inspire you....... You might need some coffee to finish this long post. :) :)

So what I did is I stepped back and looked at what Gedcom is supposed to do. It is supposed to (kind off) define humans, their interactions, and the places they have or are on: 1:relative to eachother, 2: on earth (PLAC) and 3: in time (DATE/TIME).

So individuals were defined (INDI), they are driven by Events, which have consequences. Each individual has different characteristics (and here we will only look at the characteristics/properties that are important for a family tree)

This discussion is about Names, so lets start there. Every person has one or more names, those are important, when 2 people meet they start with that and they might say: "Hello I am Sarah Smith" and the other says "Hi I am Peter Dupont" And both know who the other is. But suppose it would be like this: "Hello I am Sarah Smith" and the other says: "Hi I am pope John". Then Sarah is sure that the other person has another name, because "Pope" is assigned when that person becomes Pope, so that Name was the consequence of an Event.

Now wait a second, that should mean NAME does not belong to an individual directly, but it belongs to the event that happened for that individual. So in fact there is something in between. So it is not: INDI.NAME But it should be: INDI.EVENT.NAME Name should be 1 level lower. Ok lets see what we get if we do this for birth:

That would be: INDI.BIRT.NAME Hey look, by putting the NAME in that position, we dont need a NAMETYPE "birth" anymore, because if NAME belongs to the tag BIRT, the name given inside this tag BIRT, IS, by definition, the BirthName.

You GET your name at the birth event. Its not like you are born WITH a name, you get it from your parents, its an event/action, your parents give it to you. So its not like: "Hello mum and dad, nice to meet you, I am Peter!" :) :)

And more, the name already existed BEFORE you were born, Mom and Dad had 9 months to think about your name, unless the birth is a complete surprise, but fortunately that rarely happens.

When we add more tags to BIRT we might have:

INDI.BIRT.NAME INDI.BIRT.DATE INDI.BIRT.PLAC

Now look at that, we solved another problem, NAME is now connected to a DATE (This connection was already requested in other discussions about NAME) and NAME is combined with a PLAC. But at the same time NAME now also is combined with a NOTE, a SOUR etcetera. But if we want we could still also have: INDI.BIRT.NAME.NOTE This last thing being a NOTE just for the NAME, and not for the BIRT. So we should not need NAMEType BIRT anymore.

=============================

OK so that was the NAME type BIRT. What other Name types do we have:

I will start with some "easy" ones first.

---

name type Adoption, a type that maybe, will be in the next minor.

INDI.ADOP.NAME INDI.ADOP.DATE INDI.ADOP.PLAC

Again, because NAME is part of ADOP, this name MUST be the evential name change for the child at the time of adoption. And also now there is a DATE and PLAC of adoption added without any further action. (same is true for SOUR etcetera) If there is no name change, there might be no NAME here. Or we could say there should always be a NAME tag here. And also, there might be INDI.ADOP.NAME.NOTE . . . (note just for the name) as well as: INDI.ADOP.NOTE . . . . . (NOTE for the ADOP itself)

If this would be chosen, there is no need to add the nametype ADOPTED to the next minor.

INDI.FAMC.PEDI, not sure if there should be a NAME here. Anyone??? (if ADOP is obligatory, PEDI could go without NAME?)

---

Name type RELIGIOUS (might be in next minor) (Proposed to be used for: Religious name, name adopted after joining a religious order) This one is for Pope John above.... :)

INDI.ORDN.DATE INDI.ORDN.PLAC INDI.ORDN.NAME

Same as ADOP. RELIGIOUS not needed.

---

name type DIVORCED (might be in next minor or not) When I read gedcom 5.5.1 and 7 correct it is: Currently: FAM.HUSB FAM.WIFE FAM.DIV.HUSB FAM.DIV.WIFE FAM.DIV.DATE FAM.DIV.PLAC

So with our NAME added we would now get: FAM.HUSB FAM.WIFE FAM.DIV.HUSB FAM.DIV.HUSB.NAME FAM.DIV.WIFE FAM.DIV.WIFE.NAME FAM.DIV.DATE FAM.DIV.PLAC FAM.DIV.SOUR

Because the 2 NAMEs are part of the divorce, they must be the names after the divorce. So no need for Nametype DIVORCE, and the names have a date, place, source and more at the same time.

Same will be true for MARR, ENGA etcetera. Although not for every of these tags a NAME will/might be needed. But it IS possible.

---

We will look at MARR:

MARR, Marriage (Tag MARR already exists)

We will get: FAM.HUSB FAM.WIFE FAM.MARR.HUSB FAM.MARR.HUSB.NAME FAM.MARR.WIFE FAM.MARR.WIFE.NAME FAM.MARR.DATE FAM.MARR.PLAC

A marriage is between 2 people, normally (in older times) the WIFE got the lastname of her husband. But today the WIFE might keep her own name, and here in the Netherlands, it is now possible for each partner to use the partners lastname when married, or add your partners lastname after your own lastname, or first have your partners lastname, followed by yours. So you can all do that now with the above. And the responsability is at the user, not at the program.

---

Proposed Name type MAIDEN (in next minor?)

Dont think we need that. When a girl is born she gets her maiden name. So BIRT.NAME is her maiden name. When she gets married, we now have a MARR.WIFE.NAME and we can put her husbands name there or anything else that is found. When there is a divorce, the user puts back her Maiden- (Birth-) name there.

---

Name type ESTATE (might be in next minor) (Proposed to be used for: (House name, name adopted after moving into or marrying in a house/farm) Here I need help. I guess, when someone marries into a farm, we have already covered that with the MARR tag above. Will that solve this Nametype completely?

No matter what If we start removing NameTypes, and shifting the NAMEtag into events, there shouldnot be any NameType left, otherwise the adding of new Nametypes will start all over again.

---

That leaves us with two more NAME types: UNIFIED (Unified spelling for a family name) VARIANT (Different spelling for a Name, based on other languages such as Latin, French)

++++ First UNIFIED:

I suppose this is meant for cases where, based on birth and marriage and death documents, the name of the same individual is written slightly different from other documents about this individual. Like in my tree I have someone, I now have described as:

"Berend (Berent) / Karstjens (Karsijns Carsijns Karsijs Karsens, Karsjens, Karsijn?, Carsjen?, Karsje(n)(s), Kasje? Carsen, C(K)arsien(s), Carst, Carsten(s), Carstes), Karst(en)(s), Karst(j)es, Kast, Kasje, Karst(en)(s),Karstes, Karsties"

Yes, very unreadable. Lots of documenst, pointing to him, his wife, his children gave different spellings for his name, while they really mentioned him, or one of his kids.

But because I have to dig in archives, I dont want to lose any of these names, otherwise I might miss information about him, because the name used in that archive is not the general name I might have choosen for the family.

Now suppose we add a new event, something like ALTN (alternative Name) to the individual event structure. Then, when i find for instance a document for a daughter getting married, and I see on that document a different spelling of her fathers name, I can add the ALTN event to her father, with the name spelling I found, with the date and place of the marriage of that daughter. Because each event has a SOUR, I can let that point to the same SOUR as used for the Daughters wedding. So instead of that stupid long name, that father will have a whole list of extra events. And because they have a DATE I can sort them and get a list of the names inside.

Problem with this is, that whole list of names is only detectable from that father, and I would rather have something separate, an entity kind of thing, with all name variants inside, that i can simply attach to each family member. The only thing I can think of for this is create a NOTE Entity, put the names in there and attach that note to the INDI's I want. Further, that many extra events do not make the fathers INDI very readable either. So this might need more thinking.

But we could add an event UNIN (Unified Name, or find a better name) Where we define the one and only name to be used when kids, or parents of that father, are added. Then we, the users are in control, and the program would use that name, in stead of the birthname. Not really happy with this I must say, but sofar no other solution found.

++++ VARIANT: A different spelling, in another language, is (I think) caused by an event. When someone moves into another country, he/she might adapt his/her name, to a name thats easier to read, and or, pronounce in that country.

To solve this we need another event, that I was surprised not to see in the Gedcom specs. I started by saying we define among other things places where people live. But that means we need an event to denote they go from one place to another, they MOVE. Moving does not necessary happen at the time of the events we now have (BIRT, MARR, ORDN etcetera)

So suppose we define an INDI.MOVE event. That will have a DATE a PLAC (where they arrive!!) and, if necessary, a NAME. We can sort the MOVE's on DATE. Then we can look at the PLAC, and we know from where to where they moved. A PLAC has jurisdictions. If the country jurisdictions of INDI.MOVE.PLAC differ, we look if the destination (so INDI.MOVE.PLAC) if that has a NAME, that differs from a NAME in any of the move sequences before that. If so, thats the name to use from then on. We need a starting MOVE, but we have that always, thats when the child is born. So when we add a BIRT, we should also add a MOVE (even if in fact the child does not move, although in a certain we it does, it enters life at a certain Date/time on a certain place) We will not discuss here where it might have come from.... :)

---

Now, according to what i have read in this and other threads, we have the problem of clans and tribes and castes (India) And the fact a person can be in more than 1 tribe or whatever they were, and can get names based on that.

Again look at how people react and live. We are, or want to be, member of a group. A clan, a tribe, a fanclub, whatever.

So, like REPO that can contain many SOURces, maybe we should define GROUP as an entity. We give the GROUP a number, like with REPO, and a name (or title, whatever is more appropriate) like: Cherokee Tribe Mac Donalds Clan Vaishyas Caste

The following I am sure is not correct, but I wrote it down to give you an idea. You guys know way better how to structure what I mean.

An individual, same as for a Marriage can ENTER a Group and LEAVE a group. So we need 2 events for each GROUP.

We might get something like: INDI.ENTER.GROUP @G0001@ (dont know if this is correct but just to get an idea) INDI.ENTER.GROUP.DATE INDI.ENTER.GROUP.PLAC INDI.ENTER.GROUP.NAME (Name for the INDI in this group or name gotten from this group)

An INDI can be member of more then one group, so the problem where there is more then one name for an indi, depending on the group he is a member of, might be solved. Now I am sure if you think this could work, you might come up with tags that should go inside the group.

With the above system, the user is in control. He/she decides, depending on investigations, what name goes where. After that, the program working with the gedcom has enough information to know what to do and what name to use.

Further, because NAMEs now have a DATE, we can sort names on date. So we can get a timeline of a persons NAME.

Ok, hope you are still with me a bit. Now I will open my umbrella and hide underneath, so the rain can start pooring down.

:) :)

Tineke

[Norwegian-Sardines]

@mother10

I applaud your thought process in the above dissertation! GEDCOM has never been “normalized” very well, and if you look back at all of the iterations and redirections, it has a lot of baggage.

In a database we would need to create a NAME Record that we can index all of the names used by an individual, we would also need for all events and potentially attribute to require a name associated with the event so that a report could follow a name thru its history. Remember too that sometimes a name does not actually change over time but has incorrect entries in sources. The person may alway have one name throughout their life, but sources record different, variations of, or incorrect names.

[mother10]

@Norwegian-Sardines Thanks for the compliment.

About a NAME record: As you say, and as you could see from my silly example of so many lastnames, indeed all those "names" might just be 1 name, spelled in many different ways. But i need them all, to find more info about that person. And not just more about him, but also for more family members with that same lastname. So NAME maybe should be an entity NAME, with 1 event for each spelling difference I find, with DATE and PLAC at least for that spelling variant. But also a pointer to the individual where I found that name variant. So in fact that Entity could contain variants of the names for more family members. When I then connect that Name entity to each person involved, I have one place where I can add name all variants I encounter, and many places (all persons that link to this NAME entity) from where I can see all name variants. That way investigating a member of this family will be easier, because for whatever member I am working on, all name variants are close.

Now this might look terrible, but in my tree (3200 people) 90% or more just have 1 name.

[Norwegian-Sardines]

@mother10

Now this might look terrible, but in my tree (3200 people) 90% or more just have 1 name.

In Norway an inherited surname was not required by law until 1923. Patronymic and farm names prevailed! So everyone in rural Norway had multiple name identities.

[tychonievich]

Thanks for all this commentary! I understand the various topics much better than I did before.

From a "changes to the GEDCOM standard" standpoint, I interpret this conversation to have arrived at these points:

1. There is a daily-use / common / informal name type, such as roepnaam.
2. There is a primary / called / main name part type such as rufname.
3. These both appear in many cultures, with varying levels of formality. Some appear on official records, some on announcements and other less-official records, some mostly in speech. Some last an entire lifetime, some only for a portion thereof. The specific terms "roepnaam" and "rufname" suggest specific cultures, formalities, and lifetimes of these names and may not be the best terms for an international standard.
4. These both overlap with other name/name part types; for example, roepnaam is both daily-use and TYPE BIRTH; rufname is both primary and GIVN. The 7.0 spec does not support multiple types for the same name, and is unclear if it can support multiple name parts with the same text.
5. These topics run into many other topics related to names (and beyond) that also should be addressed.

Have I got that right? Anything I am missing or misrepresenting?

If I do have that right, do we have proposed action items?

• Is there something we should add to the technical FAQ for 7.0?
• Is there something we should add (without removing or changing what's there) in 7.1?
• Is there a better structure we should adopt instead of the current structure in 8.0?

[mother10]

@tychonievich First a comment, please get in touch with the thread: https://github.com/FamilySearch/GEDCOM/discussions/471 I proposed there to add DATE to a NAME. But if all this discussion here, hopefully leads to a shifting of NAME to inside an event, as I described in that really long post, maybe postpone adding DATE to a NAME and prevent doing unnecessary work.

I think those 5 points are correct.

About point 4: Because now we have to define a name by a NAME type, thats where the trouble comes from. If we would shift the NAME tag to where it (according to me) belongs, namely INSIDE the event that causes that name, there is no problem anymore. It will be obvious what kind of name it is. And we can get rid of all NAME TYPE's we now have, and all others that are now asked for. The single fact we need NameTypes to tell what kind of name we actually mean, to me, proves NAME is at the wrong place.

So that is, in fact, exactly what you said in point 5

Technical FAQ: Roepnaam, for now only, could be done the same way as rufname. And with type DAILYNAME added.

About 7.1 If it looks like name should be shifted in 8.0, to the event it belongs to, I would say: Think now about where, at which events, it looks like a NAME tag should be added in version 8 (roughly), and make sure to add NAME TYPE's NOW, for each of those. (If they dont already exist) That way, when version 8 will arrive, programs can convert the "old" way of defining NAME, into the new way. The NAME TYPE will than tell the program where that name belongs, so it can convert the gedcom without problems. Nametype will tell where it should put that particular NAME.

Structure for 8: Shift NAME to where it belongs, inside an event. That wil automatically give NAME a date, a place and many more things.

There also would need to be some kind of MOVE event, because people tend to change there place of living. In fact it is odd to think in the old days PLAC was defined. But nobody realized that PLAC might change many times in a live so there should be an event describing that. Where someone lives is described by AND PLAC AND ADDR. Although in the old days ADDR was not what it is today, and often, for people who lived long ago, we only know roughly where someone was residing. So for those ADDR might not be possible.

But most important to me, is what i tried to do in that long post.

Step back, put another cap on your head, and look at things with fresh eyes. Try to realize what it is in fact you try to define in the gedcom. When i had to solve a problem in my life, develop something new, the first thing i do, is make a drawing. So on a huge piece of paper draw some people, have them group, make them move, add some countries, add names and other things that we now put in a gedcom, etcetera.

When you do that, the problem comes to life, and you can see the answers right in front of you. And yes, I have not had any problem I could not make a drawing of.

Hope that helps a bit.

[tychonievich]

Going back a bit, @mother10 you said in part

Roepnaam:

1. Definition: A "roepnaam" is the name someone prefers to be called by or the name they use daily, often a shortened or variant form of their official first name.
2. Usage: It is used in both informal and formal contexts, and is often a practical name that is easier for daily use.
3. Examples: "Jan" for Johannes, "Annie" for Anna, or "Kees" for Cornelis.

That definition of roepnaam is common in America and the American-English word for it is "nickname" (I don't know if other English dialects have different words for the different kinds of nicknames or not). A famous example is the former US president Jimmy Carter, who always went by the nickname Jimmy, not his legal given names of James Earl, except on official government documents like the presidential election ballot.

I agree that the word "nickname" is also used to refer to less formal names and names that are not derived from the legal name, and that that overlapping usage is an imprecision in the English language. I'm happy that Dutch has distinct words for these two ideas, but English does not: they're both called "nicknames" and would both be coded in GEDCOM using NICK given its English-language definition.

[mother10]

@tychonievich Does this mean there will be no changes, so I am forced use NICK for roepnaam?

[tychonievich]

I'm not the final word on this, just one voice on the steering committee, but you defined roepnaam as a subset of the meaning of "nickname" so I'm not seeing the need for a separate structure. But that doesn't mean we shouldn't do something about the ambiguity present in the word "nickname" and thus inherited by the structure type NICK.

• We could remove NICK and replace it with two more-narrowly-defined structures, perhaps DAILY and CASUAL, but that would make it very hard to convert from 7.0-and-before files to the new version (in most files the data needed to do so would not be present).
• We could add an optional substructure to NICK that clarifies what kind of nickname it is: is it a preferred daily-use name/roepnaam or an informal friends-and-family name/bijnaam?
• A kind substructure could also be useful with GIVN (is it a primary/rufname given name or a secondary given name?) and SURN (is it the primary used-by-itself surname or an additional surname?).

[mother10]

Well I think our opinions differ as bit. I dont read in that definition that Roepnaam is a subset of Nickname. I think there is something very important missing in that definition then, the fact that roepnaam is always given to you at birth (as i mentioned in another post). While nickname is given later in life. Further you only have 1 roepnaam. But you can have any amount of nicknames.

So I guess I was wrong then by just copy pasting from that bot. And not adding the 2 things I just mentioned.

You were right in saying the Dutch have two distinct words for roepnaam and nickname. Thats because in Dutch they are certainly not the same thing. Roepnaam is always a decent name, in Dutch, nickname can be funny, ugly, contain numbers and all that.

Our famous footballplayer Johan Cruijff was nicknamed "Number 14", but he was never addressed personally like that. Only when people talked ABOUT him they called him that. So I would never use NICK to put in someones roepnaam.

[fisharebest]

I'm happy that Dutch has distinct words for these two ideas, but English does not: they're both called "nicknames" and would both be coded in GEDCOM using NICK given its English-language definition.

I'm not comfortable with the idea that we won't represent concepts that don't have simple English words to label them. Or that we mangle non-English constructs to fit English definitions.

I appreciate that the roepnaam is just the given-name, but in order to display a name we need it in full. We cannot assemble a NAME from its NPFX, GIVN, SPFX etc., parts.

For example, we cannot generate Johan Cruijff from this:

1 NAME Hendrikus Johannes /Cruijff/
2 _ROEPNAAM Johan

But, the following structure could work - and would fit in with the current GEDCOM structure.

1 NAME Hendrikus Johannes /Cruijff/
2 GIVN Hendrikus Johannes
2 SURN Cruijff
1 NAME Johan /Cruijff/
2 GIVN Johan
2 SURN Cruijff
2 TYPE ROEPNAAM

[albertemmerich]

I'm not comfortable with the idea that we won't represent concepts that don't have simple English words to label them. Or that we mangle non-English constructs to fit English definitions.

I agree. There are more examples. One being discussed in Germany is "confirmation" (tag CONF). Depending on the religion this covers different events, in German called "Firmung" (i.e. for the catholic church) or "Konfirmation" (for lutheran church). German users ask for an unique treatment of this situation. As long as GEDCOM spec does not offer a solution, we will find users' input like

1 EVEN
2 TYPE Firmung

which is really bad as it is language dependent, and does not use the tag CONF defined for theses events.

[mother10]

I agree with @fisharebest If I had to add myself it would be:

1 NAME Catharina Johanna Elisabeth /Xxxxx/ 2 GIVN Catharina Johanna Elisabeth 2 SURN Xxxxx 1 NAME Tineke /Xxxxx/ 2 GIVN Tineke 2 SURN Xxxxx 2 TYPE ROEPNAAM

But that would mean we need a Type ROEPNAAM Or, as discussed before, a Type DAILYNAME, to make it more usable for others.

[Norwegian-Sardines]

I’m just now getting back to cell service, I’ve been out camping. I’m in the process of reading all comments.

In addition to what Luther said (if correct), some things to remember and keep in the back of your mind.

1. GEDCOM v7+ only requires that the file contains a NAME tag and that all name entries must therefore provide enough information in that tag to identify the individual correctly. (I think this is somewhat in line with Greg’s point)
2. GEDCOM v7.0.+ is more or less set in stone, with only minor tweaks to the verbiage allowed at this time. Any rethinking of the NAME structure must come with v8, this includes a sizable number of cultural and historical factors not found in this discussion many of which do not have the exposure found in most (if not all) mainstream programs that tend to drive future plans for GEDCOM!
3. The best way to introduce some NAME changes (for that matter the sizable list of suggested tags) to GEDCOM and get them introduced before v8 (which could be years away or never) and to embrace the concept of using the TYPE tag already in GEDCOM. I’ve introduced this concept in other threads!

GEDCOM must (in my opinion) move away from just adding more tags to support concepts (many of them cultural, or language based) that are already found (or have similar meaning) in the current GEDCOM.

I would endorse the use of NAME.TYPE to include cultural and personal concepts like “preferred name”, “nick name”, “Roepnaam”, “rufname”, “farm”, “patronymic”, “generational” along with the current values of “married”, “aka”, “birth” (and more). These enumerations, must also leave open the possibility of “other” as an option with a phrase tag.

This is also the same concept that I would use to “fix” the problem that some religious concepts that don’t use the term “confirmation” like “Firmung”, (but don’t confuse “confirmation” and “konfirmation” which is just imo a translation). Personally, I think Firmung can be added as an enumeration to CONF.TYPE for GEDCOM v7.1 and then in v8.0 CONF tag can be removed in favor of a new more encompassing tag possibly called SACRament with TYPE enumerations of, “confirmation”, “firmung”, and others to be determined. The same could be true about other tags, for example in v8 add a tag called BMITZvah (gender neutral term “B-Mitzvah”) with enumerations of Bat Mitzvah, and Bar Mitzvah.

Obviously adding/removing attribute/event tags is reserved for GEDCOM v8, but adding enumerations to the TYPE tag could be acceptable in v7.1 and can be added to with v7.1.x as we learn more about other cultural inputs!

[mother10]

@Norwegian-Sardines I think I understand what you say and I can agree with the fact that big changes are not to be done now..

Did I understand correctly that you would agree with a NAME.TYPE DAILYNAME ? That would be fine with me, as I already said in the post just before yours. And if that would indeed be DAILYNAME it could be used for others too like RUFNAME, thats what I think.