-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add something for Dutch "Roepnaam" (CALLNAME) #473
Comments
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! |
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). |
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. 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. 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......) |
Then this is like the German Rufname! Which we have also discussed! https://github.com/fisharebest/gedcom-name/blob/main/call-names.md |
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? |
"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. |
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 One solution could be to create a singular tag (call name, familiar name, ?) with an enumerated |
By the way, in Norway the Rufname equivalent is “kallenavn”. |
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 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! |
Discussed in steering committee 30 MAY 2024
|
Will this new |
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:
|
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 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 |
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. |
I was just thinking: Maybe a term like DAILYNAME would work? |
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 one of the major issues forgotten in this thread is that not all software even support the |
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. |
GEDCOM-L had decided to use with GEDCOM 5.5.1
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. |
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:
|
Doesn't this imply that @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? |
Dont know if I fully understand this, but i would say roepnaam only applies to Tineke. Not to xxx, xxx thats my lastname. 1 NAME Catharina Johanna Elisabeth /Xxx/
Do not fully understand this either. When I fantasize I should say it should display: Tineke xxx 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.) 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/ 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 |
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??) |
@fisharebest I think i just added that |
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! |
As I indicated before and @fisharebest kind of touch on, display names and many software applications only use the |
Thanks for the clarifications, @Norwegian-Sardines and @mother10. Is rufname the same idea that GEDCOM-X calls "primary"?
(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?
(I'm not proposing those as the final draft, just trying to understand the usage better) |
@mother10 |
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]>
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]>
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text * Update extracted files (#508) Co-authored-by: Luther Tychonievich <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]>
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text * Update extracted files (#508) Co-authored-by: Luther Tychonievich <[email protected]> * Increase largest PLAC example (#514) * Increase largest PLAC example resolves #512 * Update specification/gedcom-3-structures-3-meaning.md * Update extracted files (#515) Co-authored-by: Luther Tychonievich <[email protected]> * Fix validate-yaml warnings (#513) Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]>
Accidentally closed based on one quite-small PR |
This draft was created based on conversation with members of the names working group in fisharebest/gedcom-name#27 and #473. The text is mostly new, though, and may have failed to capture some elements of those conversations. A separate v7.1 draft is anticipated once conversation on this draft stabilizes.
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text * Update extracted files (#508) Co-authored-by: Luther Tychonievich <[email protected]> * Increase largest PLAC example (#514) * Increase largest PLAC example resolves #512 * Update specification/gedcom-3-structures-3-meaning.md * Update extracted files (#515) Co-authored-by: Luther Tychonievich <[email protected]> * Fix validate-yaml warnings (#513) Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * Update changelog.md (#525) * Update changelog.md We've been making changes without updating the changelog. This summarizes the changes since v7.14 was released. * Update changelog.md * Update changelog.md --------- Co-authored-by: Dave Thaler <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]>
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text * Update extracted files (#508) Co-authored-by: Luther Tychonievich <[email protected]> * Increase largest PLAC example (#514) * Increase largest PLAC example resolves #512 * Update specification/gedcom-3-structures-3-meaning.md * Update extracted files (#515) Co-authored-by: Luther Tychonievich <[email protected]> * Fix validate-yaml warnings (#513) Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * Update changelog.md (#525) * Update changelog.md We've been making changes without updating the changelog. This summarizes the changes since v7.14 was released. * Update changelog.md * Update changelog.md --------- Co-authored-by: Dave Thaler <[email protected]> * EXID.TYPE for BillionGraves.com and WikiTree identifiers (#540) * EXID.TYPE for BillionGraves.com and WikiTree identifiers Fixes #539 * Update exid-types.json Co-authored-by: Luther Tychonievich <[email protected]> * Apply suggestions from code review Co-authored-by: Luther Tychonievich <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * v7.0.15 release (#537) Co-authored-by: Dave Thaler <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]> Co-authored-by: elyoh <[email protected]>
I tried to follow the discussion but might have skipped a few posts. As a Dutch myself I understand that Mother10 sees her 'online' name as a nickname. And her day-to-day name Tineke as a Roepnaam or Call-name. But what the label is, is probably not the main issue. It's what we want to achieve. I tried to find a good example in English but it seems to be very uncommon. Let's take both Richard Herbert Cheney and James Paul McCartney as example and combine the case. This is very common in Dutch. So let's assume the president is called Herbert Richard Cheney and the whole world knows him as Dick Cheney. Even his mother instructed everybody to call him Dick. Post would be send to Dick Cheney etc. Only his passport and bank-account would mention Herbert Richard or H.R. Cheney. But never Herbert Cheney, Herbert R. Cheney or H. Cheney. In Dutch trees it is common to show his name in the textual representation as Herbert Richard (Dick) Cheney, an alternative could be Dick Cheney, Herbert Richard Cheney or Dick (Herbert Richard) Cheney. Indicating his official name and his day-to-day name. But this is way to large to show in a graphical representation. There it would be common to just use just Dick Cheney. Writing down H.R. Cheney or Herbert Cheney would confuse everybody. This is why NICK would contain the call-by name in a Dutch GEDCOM. Then take the case of Elton John. A textual representation would show something like: Elton John (born as Reginald Kenneth Dwight) or Reginald Kenneth Dwight (better known as Elton John). The graphical representation would probably show Elton John or Reggie Dwight, probably depending if the audience is the public or his family. I mention this because this case could overlap with Mother10 using that name as Nickname, but I would consider it more of a Stage-name. |
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text * Update extracted files (#508) Co-authored-by: Luther Tychonievich <[email protected]> * Increase largest PLAC example (#514) * Increase largest PLAC example resolves #512 * Update specification/gedcom-3-structures-3-meaning.md * Update extracted files (#515) Co-authored-by: Luther Tychonievich <[email protected]> * Fix validate-yaml warnings (#513) Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * Update changelog.md (#525) * Update changelog.md We've been making changes without updating the changelog. This summarizes the changes since v7.14 was released. * Update changelog.md * Update changelog.md --------- Co-authored-by: Dave Thaler <[email protected]> * EXID.TYPE for BillionGraves.com and WikiTree identifiers (#540) * EXID.TYPE for BillionGraves.com and WikiTree identifiers Fixes #539 * Update exid-types.json Co-authored-by: Luther Tychonievich <[email protected]> * Apply suggestions from code review Co-authored-by: Luther Tychonievich <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * v7.0.15 release (#537) Co-authored-by: Dave Thaler <[email protected]> * Update exid-types.json (#543) * Update exid-types.json Resolve incorrect URIs as noted in #539 * move /name * move /name * move /name * move /name * Clarify a deprecation (#547) * Update extracted files (#542) Co-authored-by: Dave Thaler <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]> Co-authored-by: elyoh <[email protected]> Co-authored-by: Dave Thaler <[email protected]>
Adding to this: It's was common to name someone with 3 or 4 names, pointing to multiple important family members. Could be in order of importance or not. We refer to Cornelia Wilhelmina Aleida Caterina as Doopnamen -> Baptist names (sometimes even if children aren't baptized) or Volledige voornamen -> Full first names A Catholics could call there son: It is also possible to call someone: Important to indicate that we don't register middle names. Everything is part of the first name, just not the Roepnaam. And just a last step. parts like "van", "van de", "de", "het" are part of the last name, but are "tussenvoegsels" and are not part of the sorting order. When sorting we would write: [Amsterdam, Jan-Willem Gerrit van] but when listing the last name it would be [van Amsterdam] or [Amsterdam, van] But all-in-all it is still the same as Herbert Richard (Dick) Cheney. With the only difference that it is very uncommon in English to have the Nickname derived from the second name. And it is hard to register the Full Name and the Nickname and display both in the correct order. FIRSTNAMES: Cornelia Wilhelmina would not be completely right, because we lack middle names, but at least in reporting we could have control over what is displayed, store this as default and even overwrite when someone marries someone from a different culture. FIRSTNAMES: Yoko This would fix the cultural fault of writing Yoko Ono to the correct Ono Yoko. |
Here we have a proposal for a new structure of NAME, using the substructures NAME_PIECES, and a new substructure "TEXTDISPLAYFORMAT" to build the NAME payload from the NAME_PIECES. |
I think there is a distinction between "knowing which part of the name is a surname/prefix/suffix/whatever" and "re-constructing a full name from its component parts". What problem are we trying to solve? Individuals have long names (Richard Herbert Cheney) and shorter versions (Dick Cheney). In some contexts, we'd want the long one. In others, we'd want the shorter one. In this case, is it simpler to simply store both long and short forms? 1 NAME Richard Herbert /Cheney/ |
True. But in my culture it is normal to: In other cultures it is normal to: So many reports try to correct the name to fit the situation, depending on the culture of the writer of the report. But this is impossible if parts of the name are not labeled correctly. So yes, there should be multiple types of names saved in GEDCOM, that way reports can show names without making assumptions. There are some conventions that try to fix. Like James Paul* /McCartney/ jr. or Richard (Dick) Herbert /Cheney/ or /Ono/ Yoko where slash indicate what part is the familyname, what part is the common name and what part is derived from another part. A dutch solution could be to write Beatrix /Nassau, van/ indicating that the part behind the comma should be in front of the comma, except in the index. Maybe there is a convention to tell what part of the last name is derived from the sex? And applications could/should make modular input forms to be able to switch between cultural differences. All versions could be made with the appropriate cultural form and stored within the GEDCOM without guesswork from the export and import and/or report. Because all the guesswork breaks the culture. Edit: typo |
In cultures where the surname is written first Asia/Hungary we enter the name like this: 1 NAME /surname/ given name(s) In applications where you want to display the name “Jon van Nassau” and index the value Nassau, we enter it as follows: 1 NAME Jon /van Nassau/ |
In cultures that have surnames with gender based ending such as Eastern Europe, we know from Wikipedia:
Therefore: Male: Female: |
1 NAME Maria /Smolenska/
2 SURN Smolen My application does not offer this, as the payload of NAME always is put together by the NAME_PIECES which the user entered. So I have 1 NAME Maria /Smolenska/
2 SURN Smolenska |
I think a lot of applications look at the SURN tag and think it should contain the surname. In these examples it looks like you specifically use the SURN tag for function, because the surname is "van Nassau" and I think Smolenska? If it is used for function it should contain "Nassau, van" because the name differs from "Nassau". Some reports might think showing a short version of the name could be NICK SURN. But that would be wrong. |
We have discussed that (I believe it has been added to the specification) that the SURN tag can be used to support indexing a name that is gender neutral as the program I use already does. In the case of Nassau vs "Nassau, van" being a different name we had not discussed this. Note: crossed out. The current specification does allow the use of multiple SURN tags and does not use a comma delimited list any more, so this would be valid:
|
I do not think, "van" should be part of the 1 NAME Jon /van Nassau/
2 GIVN Jon
2 SPFX van
2 SURN Nassau and the application can do all things wanted by users. |
Albert, you must have seen the discussion we had two years ago about the use of the SURN tag as a true indexing value rather than just a duplicate of the NAME tag! The GEDCOM specification already says:
The last part of the quote pertains to this discussion. My application allows for indexing and grouping based on the SURN tag that would allow the root name to be entered rather than the gender specific name. |
I agree 100% with your indication that van is not in this context (but in others) a Surname Prefix. I corrected my comment above and indicate the following would be ok in v7.0 of GEDCOM.
The index and grouping would be on "Nassau, van" which would be different than just "Nassau". |
Discussed in steering committee The spec currently defined name in terms of splitting the name and structuring its information. It allows "for the payload to contain information not present in any name piece substructure" but does not speak either way to the inverse (a name part that is not part of the name payload). We think that having a SURN that is not part of the name is not appropriate in 7.0, but the spec does not fully define "part of". Elsewhere in this issue's discussion we propose adding not-part-of use in 7.1 and/or 8.0.
|
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text * Update extracted files (#508) Co-authored-by: Luther Tychonievich <[email protected]> * Increase largest PLAC example (#514) * Increase largest PLAC example resolves #512 * Update specification/gedcom-3-structures-3-meaning.md * Update extracted files (#515) Co-authored-by: Luther Tychonievich <[email protected]> * Fix validate-yaml warnings (#513) Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * Update changelog.md (#525) * Update changelog.md We've been making changes without updating the changelog. This summarizes the changes since v7.14 was released. * Update changelog.md * Update changelog.md --------- Co-authored-by: Dave Thaler <[email protected]> * EXID.TYPE for BillionGraves.com and WikiTree identifiers (#540) * EXID.TYPE for BillionGraves.com and WikiTree identifiers Fixes #539 * Update exid-types.json Co-authored-by: Luther Tychonievich <[email protected]> * Apply suggestions from code review Co-authored-by: Luther Tychonievich <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * v7.0.15 release (#537) Co-authored-by: Dave Thaler <[email protected]> * Update exid-types.json (#543) * Update exid-types.json Resolve incorrect URIs as noted in #539 * move /name * move /name * move /name * move /name * Clarify a deprecation (#547) * Update extracted files (#542) Co-authored-by: Dave Thaler <[email protected]> * Fix documentation confusion about HEAD-SOUR-DATA (#553) * Make HEAD.SOUR.DATA wording consistent between two places in spec Signed-off-by: Dave Thaler <[email protected]> * Deprecate HEAD.SOUR.DATA Signed-off-by: Dave Thaler <[email protected]> * Update specification/gedcom-3-structures-1-organization.md * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add note about blank payloads (#554) * Add note about blank payloads Based on discussion in issue #495 Signed-off-by: Dave Thaler <[email protected]> * Update specification/gedcom-3-structures-1-organization.md * Update specification/gedcom-3-structures-1-organization.md * Update specification/gedcom-3-structures-1-organization.md --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Always quote tags (#560) * Update generate-files to use a PAT (#557) * Fix names of workflows * Make generate-files use a PAT so that validate-yaml will run The PAT is already generated and configured in the repository secrets Fixes #503 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#555) Co-authored-by: Dave Thaler <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]> Co-authored-by: elyoh <[email protected]> Co-authored-by: Dave Thaler <[email protected]>
* Update extracted files (#443) Co-authored-by: Luther Tychonievich <[email protected]> * decribe branches in README.md (#451) * decribe branches in README.md * Update README.md * Add contact info to auto-generated YAML files (#454) Per discussion in steering committee meeting 2024-04-04, using <https://gedcom.io/community/> as the contact info because that page describes various means of contact and is expected to be updated from time to time as means of contact change. * Add CI/CD workflow to validate YAML files (#457) * Add CI/CD workflow to validate YAML files Signed-off-by: Dave Thaler <[email protected]> * Update YAML files to resolve yamllint errors Signed-off-by: Dave Thaler <[email protected]> * Update .github/workflows/validate-yaml.yml * Update .github/workflows/validate-yaml.yml --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * yamllint is recursive (#460) Avoid validating the same file multiple times https://github.com/FamilySearch/GEDCOM/actions/runs/8838156091/job/24268618756 under "Validate YAML" shows multiple occurences of files under .github/workflow since .github and .github/workflow are both passed to yamllint Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add Separation event (#459) * Add Separation event * Remove FS API reference * Fix workflow (#462) https://github.com/FamilySearch/GEDCOM/actions/runs/9044561163 failure reports: "The workflow is not valid. .github/workflows/propagate-main-to-v7.1.yml (Line: 18, Col: 3): The identifier 'merge-to-v7.1' is invalid. IDs may only contain alphanumeric characters, '_', and '-'. IDs must start with a letter or '_' and and must be less than 100 characters." This PR therefore removes the '.' that is causing the failure. Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Track request for Separated as a future FAM attribute (#469) Related to PR #459 which tracks the separation event Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Fix reference to FilePath data type (#466) Fixes #465 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Typo in README.md (#472) * Add the meaning of WWW (#480) * Add the meaning of WWW Previously (in both 5.5.1 and 7.0.0–7.0.14) `WWW` was defined only by the type of is payload. This is an attempt to fix that without invalidating any existing files. Resolves #476 * Update specification/gedcom-3-structures-3-meaning.md Co-authored-by: Dave Thaler <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> * Remove substructure-specific extension wording (#481) Resolves #478 * Add some possible additional family events for consideration (#479) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify no-FORM PLACs (#487) Resolves #486 * Define "principle date" (#492) * Define "principle date" As pointed out in #488 and #490, the definition of DATE includes the vague phrase "principle date" which could use some clarification. This is my effort to provide that clarification. Note, if competing definitions of the principle date in these contexts exists then this suggestion could be seen as backwards-incompatible and may need to be reworded as a non-normative recommendation or note. That said, I'm not aware of any conflicting definitions. Resolves #490 * typos * typo * Update extracted files (#485) Co-authored-by: Luther Tychonievich <[email protected]> * Clarify nickname (#482) * Clarify nickname Add additional clarification to nickname, explaining the word's meaning in English which is not shared by several European countries. See [this comment](#473 (comment)) and the rest of issue #473 for more on why this clarification is needed. Although #473's discussion covers many more topics, if we go back to the title and first question in the issue I think this resolves #473. * Update specification/gedcom-3-structures-3-meaning.md * Change recommendation * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#501) Co-authored-by: Luther Tychonievich <[email protected]> * Restore 3.0's definition of jurisdiction (#506) * Restore 3.0's definition of jurisdiction Restored the definition of "jurisdiction" that was present in version 3.0. Resolved #496 * Update specification/gedcom-3-structures-3-meaning.md Additional examples and less proscriptive text * Update extracted files (#508) Co-authored-by: Luther Tychonievich <[email protected]> * Increase largest PLAC example (#514) * Increase largest PLAC example resolves #512 * Update specification/gedcom-3-structures-3-meaning.md * Update extracted files (#515) Co-authored-by: Luther Tychonievich <[email protected]> * Fix validate-yaml warnings (#513) Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * Update changelog.md (#525) * Update changelog.md We've been making changes without updating the changelog. This summarizes the changes since v7.14 was released. * Update changelog.md * Update changelog.md --------- Co-authored-by: Dave Thaler <[email protected]> * EXID.TYPE for BillionGraves.com and WikiTree identifiers (#540) * EXID.TYPE for BillionGraves.com and WikiTree identifiers Fixes #539 * Update exid-types.json Co-authored-by: Luther Tychonievich <[email protected]> * Apply suggestions from code review Co-authored-by: Luther Tychonievich <[email protected]> --------- Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> * v7.0.15 release (#537) Co-authored-by: Dave Thaler <[email protected]> * Update exid-types.json (#543) * Update exid-types.json Resolve incorrect URIs as noted in #539 * move /name * move /name * move /name * move /name * Clarify a deprecation (#547) * Update extracted files (#542) Co-authored-by: Dave Thaler <[email protected]> * Fix documentation confusion about HEAD-SOUR-DATA (#553) * Make HEAD.SOUR.DATA wording consistent between two places in spec Signed-off-by: Dave Thaler <[email protected]> * Deprecate HEAD.SOUR.DATA Signed-off-by: Dave Thaler <[email protected]> * Update specification/gedcom-3-structures-1-organization.md * Update specification/gedcom-3-structures-3-meaning.md * Update specification/gedcom-3-structures-3-meaning.md --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Add note about blank payloads (#554) * Add note about blank payloads Based on discussion in issue #495 Signed-off-by: Dave Thaler <[email protected]> * Update specification/gedcom-3-structures-1-organization.md * Update specification/gedcom-3-structures-1-organization.md * Update specification/gedcom-3-structures-1-organization.md --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Always quote tags (#560) * Update generate-files to use a PAT (#557) * Fix names of workflows * Make generate-files use a PAT so that validate-yaml will run The PAT is already generated and configured in the repository secrets Fixes #503 Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> * Update extracted files (#555) Co-authored-by: Dave Thaler <[email protected]> * Don't warn about use of "on" as a YAML key (#562) Per documentation at https://yamllint.readthedocs.io/en/stable/rules.html#module-yamllint.rules.truthy Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> --------- Signed-off-by: Dave Thaler <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Luther Tychonievich <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Dave Thaler <[email protected]> Co-authored-by: Christopher Horn <[email protected]> Co-authored-by: Dylan Stephano-Shachter <[email protected]> Co-authored-by: elyoh <[email protected]> Co-authored-by: Dave Thaler <[email protected]>
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.
The text was updated successfully, but these errors were encountered: