Need clarification on use of SURN tag.

[fisharebest]

PR #141 added the following clarification:

in particular that all name parts in PERSONAL_NAME_PIECES should appear within the <PersonalName> payload.

Can I ask for some clarification on the clarification :-)

Eastern european surnames can be inflected, according to the gender, role within the family, etc,

For example, if a Polish man has the surname "Kowalski", his wife/daughters will use the inflected form "Kowalska"

In my own application, I store the root/base form of the surname in the SURN field, and the inflected form in the NAME field.

e.g.

1 NAME Maria /Kowalska/
2 GIVN Maria
2 SURN Kowalski

Would this usage be compatible with the latest definition, or must I now store the exact (i.e. inflected) variation in the SURN field.

If the exact/inflected form must be used, then the defintion of SURN might need to be updated. The current defintion would appear to include the way I'm currently using it.

A family name passed on or used by members of a family.

[dthaler]

Discussion 31 MAY 2022: Most programs will only keep one version of the surname per NAME structure and will overwrite the NAME surname, or the SURN, or just lose the SURN. So having them not match may lose data as files are transferred among different implementations.

One could however do (possibly with different TYPE or TYPE.PHRASE values):

1 NAME Maria /Kowalska/
2 GIVN Maria
2 SURN Kowalska
1 NAME Maria /Kowalski/
2 GIVN Maria
2 SURN Kowalski

[fisharebest]

One could however do…

This is not correct. NAME is defined as

Names of individuals are represented in the manner the name is normally spoken

and Maria would never have normally spoken her name using the male form of it.

[ungeahnt]

I agree with fisharebest 100%.

For the bulgarian part of my family I regularly have three names as family names: female (e.g. Marinova), male (Marinov) and some kind of plural form (Marinovi). With 5.5.1 this can be represented in a suitable and evluable way (three comma separated names):

1 NAME Velislava Velcheva /Marinova/
2 TYPE MAIDEN
2 GIVN Velislava Velcheva
2 SURN Marinova, Marinov, Marinovi

How does this work in 7.0?

Additionally, regarding PHRASE:

One could however do (possibly with different TYPE or TYPE.PHRASE values):

GEDCOM spec:
PHRASE Textual information that cannot be expressed in the superstructure due to the limitations of its datatype.

If I have understood it correctly, then a PHRASE can not be evaluated by the software (e.g. for lists). It's rather a NOTE, right? Therefore, in my opinion, it's not an equal solution.

[dthaler]

My view is that 7.0 is the same as 5.5.1 which is that this never worked reliably before either. Name piece tags are optional, and so some programs might ignore the name pieces and just use the NAME, some programs might ignore the NAME and just construct a name from the pieces, some programs will override the name pieces with what is in the NAME and export accordingly, some programs will override the NAME with what is in the name pieces and export accordingly, etc. There's no rule you can rely on for what programs do today since it was not well documented in 5.5.1. Thus, the example shown by @ungeahnt will work in one program, and fail when read by another program, and transferring a file back and forth through programs will lose data, so it cannot reliably be used for interoperation between programs. 7.0 is no better. The text put into 7.0 explains the only thing that is "safe" against data loss, which is when they match. The same would be true for 5.5.1 as well. That's my 2 cents anyway.

[Norwegian-Sardines]

My 2 cents is that:

If programs use the NAME subtags in various and contradicting ways then the correct change in the GEDCOM would be setting all subtags of NAME as {1:1} or (1:M} rather than duplicating the NAME tag down to the subtags, which renders the subtags useless. Therefore, If useless deprecate them!

I'm not advocating their deprication, rather,

On the other hand If GEDCOM provided guidance on how to use the NAME tag and NAME subtags to implement specific requirements like how to support individuals with multiple surnames, no surname, gender based surnames, patronymic names. etc., then the tags would actually have value going forward for international and historical data storage and inter program transfer!

[ungeahnt]

interoperation between programs. 7.0 is no better

With my example I'm only wanted to show that SURN could be different from NAME. Spec 5.5.1 is actually very vague in the use of SURN but it allows different (or multiple) names. Therefore the use of a root/base form for SURN and a different name for NAME is valid.

But the added text in V7 is not only a recommendation, or am I wrong?

There is stll the question how to handle these root/base form of a surname in V7. In my opinion NAME is not correct and PHRASE can't be evaluated.

[Norwegian-Sardines]

I agree 100% as well!

In some cases Eastern European "Slavic" surnames may have a stem name (names based on location or occupation) with an ending added to indicate gender. For example: kowal is the stem name for "smith". The surname suffix of -ski or -ska can be added as gender specific surnames. In cases like this I would use the stem value in the SURN tag.

1 NAME Maria /Kowalska/
2 GIVN Maria
2 SURN Kowal

Her brother might be:
1 NAME Peder /Kowalski/
2 GIVN Peder
2 SURN Kowal