Before asking for help please read "Requesting Help and Suggestions" by clicking on that tab above here.
  • Page:
  • 1

TOPIC:

Why does the gedcom structure have merged fields AND separate fields 6 days 18 hours ago #1

  • mariannevanharten
  • mariannevanharten's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
  • Posts: 458
When a person is called Antonie Bruijnis and his name is spelled in various ways, it's hard to record all possible combinations.
I like to have a gedcom record which only records the separate fields
1 GIVN Antonie
2 AKA Anthonie
2 AKA Anthony
2 AKA Antony
1 SURN Bruijnis
2 AKA Bruynis
2 AKA Brunis
2 AKA Brunings

The displayed name should be the GIVN name, if applicable the SPFX, followed by the SURN name.
In the current situation I have to record:
1 NAME Antonie /Bruijnis/
2 AKA Anthonie /Bruijnis/
2 AKA Anthony /Bruijnis/
2 AKA Anthonie /Bruijnis/
2 AKA Antony /Bruijnis/
2 AKA Anthonie /Bruynis/
2 AKA Anthony /Bruynis/
2 AKA Anthonie /Bruynis/
2 AKA Antony /Bruynis/
2 AKA Anthonie /Brunis/
2 AKA Anthony /Brunis/
2 AKA Anthonie /Brunis/
2 AKA Antony /Brunis/
2 AKA Anthonie /Bruinings/
2 AKA Anthony /Bruinings/
2 AKA Anthonie /Bruinings/
2 AKA Antony /Bruinings/

The same idea handles residence addresses (ADDR, POST, PLAC, CTRY).

Best regards,
Marianne

Please Log in or Create an account to join the conversation.

Why does the gedcom structure have merged fields AND separate fields 6 days 17 hours ago #2

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Posts: 2137
Maria,

This is one of those cases where knowing the GEDCOM 5.5.1 Standard would tell you that the following is invalid:

1 GIVN Antonie
2 AKA Anthonie

The GIVN tag only resides at level 2 and you can not add a lower order tag to the GIVN tag.

1 NAME Jane /Doe/
2 GIVN Jane
2 SURN Doe

The only truly valid “AKA” is the TYPE tag:

1 NAME Jane /Doe/
2 TYPE aka
2 GIVN Jane
2 SURN Doe
Ken

Please Log in or Create an account to join the conversation.

Last edit: by norwegian_sardines.

Why does the gedcom structure have merged fields AND separate fields 6 days 16 hours ago #3

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Posts: 2137
As far as the subtags of the ADDRESS tag, GEDCOM highly suggests not using the following subtags: ADR1, ADR2, ADR3, CITY, STAE, POST, AND CTRY.

Only use the ADDR and CONT tags as if you were creating an address label.

For Example:
1 RESI
2 ADDR 73 North Ashley
3 CONT Spencer, Utah UT84991
Ken

Please Log in or Create an account to join the conversation.

Last edit: by norwegian_sardines.

Why does the gedcom structure have merged fields AND separate fields 6 days 15 hours ago #4

This discussion has some good advice for managing multiple spellings of a surname. In particular, you can write a list of names, separated by commas, on the SURN field. However, it looks like the same technique does not apply to the GIVN field.

By the way, if the spelling of a surname changes over time, the Branches report won't display the entire family unless you add a common spelling of the surname to every Individual.

Please Log in or Create an account to join the conversation.

Why does the gedcom structure have merged fields AND separate fields 6 days 14 hours ago #5

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Posts: 2137
drblam said:

This discussion has some good advice for managing multiple spellings of a surname. In particular, you can write a list of names, separated by commas, on the SURN field. However, it looks like the same technique does not apply to the GIVN field.

Actually GEDCOM says the GIVN tag does allow for

Different given names are separated by a comma.

So you could code:

1 NAME Antonie /Bruijnis/
2 GIVN Antonie, Anthony, ...
2 SURN Bruijnis, Bruynis, ...

But my question is "WHY?"

In some cases we see various spellings of a individual's name in sources. Does this really mean they were "Also Known As" (Antonie and Anthony), or were they know as the sound that is written as (Antonie or Anthony), but never officially change there written name? Historically name spelling changes recordings were very often introduced by clergy that did not always spell very well or there was not a standard spelling for a name. Therefore I would not create multiple NAME entries for these given names just because you found it written differently in various sources.

As far as surnames it is possible that the family did change the spelling officially from Bruijnis to Bruynis but it is also possible that the recorder was not a good speller or wrote names phonetically! So again I'm not sure that all of these spelling variations are correct as an "AKA", rather a NOTE saying you found the name spelled in various forms, but standardized on xyz surname.

I have found that over time different branches of the same family alter their name slightly to follow local customs. The English language does not have the same character set as other languages. For example the Norwegian letter "ø", sometime became just "o" or the letter "Å" became the letters "Aa" and when some of my relatives moved to American they officially changed their name to reflect this spelling. These would be for me an "AKA". The German branch of the family had a different spelling than the Norwegian branch, this would also be an "AKA". As noted by drblam, I would add a common spelling to the SURN to augment grouping of names in lists.
Ken

Please Log in or Create an account to join the conversation.

Last edit: by norwegian_sardines.

Why does the gedcom structure have merged fields AND separate fields 6 days 1 hour ago #6

  • bertkoor
  • bertkoor's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Greetings from Utrecht, Holland
  • Posts: 2407

Why does the gedcom structure have merged fields AND separate fields


Because each has their own purpose and usage.
Sometimes it's sufficient to have one unstructured field containing all of the data (name, address) but for some functions it's needed to have it broken down into its components as well. You'd like a list of names to be sortable on given names and/or on the surname. You'd like a list of addresses sortable on place or postal code. You'd like a search function to come up with the right results.

Problem: recording just the parts is often not enough to reconstruct the whole again. Especially names & addresses are things that have a wildly varying structure, and it varies depending on place and time and many other factors such as the mood of whoever happens to write it down. There are many cultures where the surname comes before the given names. Hungarian, Chinese, Vietnamese, Japanese, Korean, and Basque are examples of cultures where the surname comes first. GEDCOM caters for this in the following way:
1 NAME /Kim/ Jong-il
2 GIVN Jong-il
2 SURN Kim

Even in Belgium or France for instance if you ask someone's name and (s)he knows it is for administrative purposes, there is a chance they will give it as a service to you with the surname first, followed by given names. That made sense in old punchcard systems. One field for the whole name, easy to sort on surname. These are cultural things, and culture is an evolving thing. In Slavic languages such as Polish and Russian the surname is slightly different for males and females. Simple example: Anna Kournikova is the daughter of Sergei Kournikov. GEDCOM caters for this in the following way:
1 NAME Anna /Kournikova/
2 GIVN Anna
2 SURN Kournikov

I like to have a gedcom record which only records the separate fields


You can do it that way, but then it's not GEDCOM standards compliant anymore. And then you get tied to one cultural way of reconstructing names from their parts. It gets more complicated with Spanish and Portuguese names where surnames take one of each parents and there are very complicated rules for glueing these together using small words like de, dos, y, etc etc.

Note that some users do the reverse: record just 1 NAME Given Names /Surname/ and don't bother with the GIVN + SURN sub-fields. Works like a charm. Also solves the patronym "problem" (by not stating the patronym is a given name)

it's hard to record all possible combinations


Correct. So perhaps you shouldn't ;-)
stamboom.BertKoor.nl runs on webtrees v1.7.13

Please Log in or Create an account to join the conversation.

Last edit: by bertkoor.
  • Page:
  • 1
Powered by Kunena Forum