Skip to content
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

Open
mother10 opened this issue May 27, 2024 · 87 comments · Fixed by #482
Open

Add something for Dutch "Roepnaam" (CALLNAME) #473

mother10 opened this issue May 27, 2024 · 87 comments · Fixed by #482
Labels
names working group See https://github.com/fisharebest/gedcom-name next minor

Comments

@mother10
Copy link

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
Copy link

Norwegian-Sardines commented May 27, 2024

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
Copy link

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
Copy link
Author

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
Copy link

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

@mother10
Copy link
Author

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
Copy link
Collaborator

dthaler commented May 30, 2024

"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
Copy link
Collaborator

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
Copy link

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
Copy link

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

@Norwegian-Sardines
Copy link

"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
Copy link
Collaborator

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
Copy link

Norwegian-Sardines commented May 31, 2024

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
Copy link
Collaborator

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
Copy link

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
Copy link
Author

  • 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
Copy link
Author

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

@Norwegian-Sardines
Copy link

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
Copy link
Author

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
Copy link
Collaborator

albertemmerich commented May 31, 2024

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Author

mother10 commented May 31, 2024

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
Copy link
Contributor

@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.

Screenshot 2024-05-31 at 15 06 31

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

@mother10
Copy link
Author

@fisharebest I think i just added that

@Norwegian-Sardines
Copy link

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!

@tychonievich tychonievich added the names working group See https://github.com/fisharebest/gedcom-name label May 31, 2024
@Norwegian-Sardines
Copy link

Norwegian-Sardines commented May 31, 2024

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
Copy link
Collaborator

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
Copy link

@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.

tychonievich added a commit that referenced this issue Jul 2, 2024
* 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]>
tychonievich added a commit that referenced this issue Jul 9, 2024
* 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]>
tychonievich added a commit that referenced this issue Jul 9, 2024
* 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]>
tychonievich added a commit that referenced this issue Jul 16, 2024
* 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]>
@tychonievich
Copy link
Collaborator

Accidentally closed based on one quite-small PR

@tychonievich tychonievich reopened this Jul 31, 2024
tychonievich added a commit that referenced this issue Jul 31, 2024
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.
dthaler added a commit that referenced this issue Aug 16, 2024
* 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]>
dthaler added a commit that referenced this issue Aug 27, 2024
* 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]>
@jkr-wrk
Copy link

jkr-wrk commented Sep 2, 2024

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.

dthaler added a commit that referenced this issue Sep 3, 2024
* 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]>
@jkr-wrk
Copy link

jkr-wrk commented Sep 4, 2024

Adding to this:
https://www.dutchgenealogy.nl/no-middle-names/

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.
Cornelia Wilhelmina Aleida Caterina Voetjes. Everyone would call her Mien (derived from Wilhelmina), because the parents like that name, or later Tina (derived from Caterina) because the child does not like to be called Mien Voetjes (translated to My Feet). We even see official documents where the birth certificate says Cornelia Wilhelmina Aleida Caterina Voetjes but the birth certificate of the child would call the mother Tina Voetjes.

We refer to Cornelia Wilhelmina Aleida Caterina as Doopnamen -> Baptist names (sometimes even if children aren't baptized) or Volledige voornamen -> Full first names
And Mien as Roepnaam -> Name to address you in day to day conversation

A Catholics could call there son:
Otto Diederik Maria van Amsterdam (Rick)
With the Maria part indicating to being Catholic, the Otto pointing to fathers father and the Diederik part pointing to mothers father. But it would be silly to call him Diederik Otto Maria -> D.O.M. because that would be "dom" (stupid).

It is also possible to call someone:
Jan-Willem Gerrit van Amsterdam -> would be called Jan-Willem (the dash indicating it is one name, most of the time)

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
MIDDLENAMES: Aleida Caterina
NICKNAME: Mien
LASTNAMEPREFIX: van
LASTNAMES: Amsterdam
TEXTDISPLAYFORMAT: %FIRSTNAMES (%NICKNAME) %MIDDLENAMES %LASTNAMEPREFIX %LASTNAME %LASTNAMESUFFIX
GRAPHICDISPLAYFORMAT: %NICKNAME %LASTNAMEPREFIX %LASTNAME %LASTNAMESUFFIX
TABLEVIEWFORMAT: %LASTNAME %LASTNAMESUFFIX, %FIRSTNAMES (%NICKNAME) %MIDDLENAMES %LASTNAMEPREFIX

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
MIDDLENAMES:
NICKNAME:
LASTNAMEPREFIX:
LASTNAMES: Ono
TEXTDISPLAYFORMAT: %LASTNAMES %FIRSTNAMES
GRAPHICDISPLAYFORMAT: %LASTNAMES %FIRSTNAMES
TABLEVIEWFORMAT: %LASTNAMES %FIRSTNAMES

This would fix the cultural fault of writing Yoko Ono to the correct Ono Yoko.

@albertemmerich
Copy link
Collaborator

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.
This might be a good way to cover very different naming conventions in different cultures, and still enabling to know which part is the surname, given name and so on.

@fisharebest
Copy link
Contributor

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/
2 TYPE birth,legal,etc.
1 NAME Dick /Cheney/
2 TYPE aka,short,etc.

@jkr-wrk
Copy link

jkr-wrk commented Sep 4, 2024

True.

But in my culture it is normal to:
split the last name in two parts to fix the name index: van Nassau -> Nassau, van
not to abbreviate all first names except the first (It's C.A.M. de Vries or Cor de Vries or C. de Vries, never Cor A.M. de Vries)
have a common name derived from any of the official names, not just the first (Cornelis Antonius de Vries -> Ton de Vries)

In other cultures it is normal to:
change the last name depending on the sex (Russia/Iceland)
change the last name depending on the first name of father (Iceland)
write the last name first in every report (Asia/Hungary)

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.
That way if I send my GEDCOM from one application to another the index will still show:
Nassau, van (in the last name index)
Dick Cheney (in the visual tree)
Herbert Richard (Dick) Cheney jr. (In the personal description)
Herbert Richard Cheney (In the official person card)
Cheney Herbert Richard (In a chinese situation)

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

@Norwegian-Sardines
Copy link

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/
2 SURN Nassau

@Norwegian-Sardines
Copy link

In cultures that have surnames with gender based ending such as Eastern Europe, we know from Wikipedia:

The -ski ending and similar adjectival endings (-cki, -dzki, -ny, -ty) are the only ones in Polish that have feminine forms, where women have the feminine version ending in -ska (-cka, -dzka, -na, -ta) instead. Historically, female versions of surnames were more complex, often formed by adding the suffix -owa for married women and -ówna or -wianka for unmarried women.

Therefore:

Male:
1 NAME Jan /Smolenski/
2 SURN Smolen

Female:
1 NAME Maria /Smolenska/
2 SURN Smolen

@albertemmerich
Copy link
Collaborator

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

@jkr-wrk
Copy link

jkr-wrk commented Sep 5, 2024

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.

@Norwegian-Sardines
Copy link

Norwegian-Sardines commented Sep 5, 2024

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. At present the comma would be viewed as a separate name in the SURN tag, but if we were to adopt the ability to use multiple SURN tags (as discussed as well) then the coma would be ok.

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:

1 NAME Jon /van Nassau/
2 SURN Nassau, van

@albertemmerich
Copy link
Collaborator

I do not think, "van" should be part of the SURN payload.
I have (in GEDCOM 5.5.1 or GEDCOM 7.0)

1 NAME Jon /van Nassau/
2 GIVN Jon
2 SPFX van
2 SURN Nassau

and the application can do all things wanted by users.

@Norwegian-Sardines
Copy link

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

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 Personal Name payload shall be seen as the primary name representation, with name pieces as optional auxiliary information; in particular it is recommended that all name parts in PERSONAL_NAME_PIECES appear within the PersonalName payload in some form, possibly adjusted for gender specific suffixes or the like.

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.

@Norwegian-Sardines
Copy link

I do not think, "van" should be part of the SURN payload. I have (in GEDCOM 5.5.1 or GEDCOM 7.0)

1 NAME Jon /van Nassau/
2 GIVN Jon
2 SPFX van
2 SURN Nassau

and the application can do all things wanted by users.

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.

1 NAME Jon /van Nassau/
2 SURN Nassau, van

The index and grouping would be on "Nassau, van" which would be different than just "Nassau".

@tychonievich
Copy link
Collaborator

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.

g7:SURN is defined as "A family name passed on or used by members of a family." That doesn't appear to use to be aligned with SURN Nassau, van, but that decision would ultimately be up to the person entering the data. Some applications could try to anticipate uses of commas like this, but that is a culturally-specific and localization-specific usage and not covered by the GEDCOM spec itself.

dthaler added a commit that referenced this issue Oct 22, 2024
* 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]>
dthaler added a commit that referenced this issue Nov 5, 2024
* 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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
names working group See https://github.com/fisharebest/gedcom-name next minor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants