SPFX or not

[mariannevanharten]

My last name is "van Harten". In Gedcom:

2 SPFX van
2 SURN Harten

Some documents about other persons with the same last name, are writing "Harten" as last name (without "van") or "Harte" or "van Harte".
Is it allowed to use the following Gedcom snippet to indicate that there is no SPFX

2 SPFX van, , van,
2 SURN Harten, Harten, Harte, Harte

Note: in the last snippet the SPFX has a comma als laatste teken.

Best regards,
Marianne

[dthaler]

Unlike GEDCOM 5.5.1, FamilySearch GEDCOM 7.0 does not use commas for any special purpose in SPFX or SURN. See https://gedcom.io/migrate/#surn-values for examples of the differences. The same applies to SPFX. So certainly your second example would not be correct in 7.0 since you didn't intend commas to be literally part of your name. In 5.5.1, SPFX is defined as

SPFX <NAME_PIECE_SURNAME_PREFIX>

with

NAME_PIECE_SURNAME_PREFIX:= [ <NAME_PIECE> | <NAME_PIECE_SURNAME_PREFIX>, <NAME_PIECE> ]
NAME_PIECE:= {Size=1:90}

where the 1:90 means that a 0-length piece is not permitted, so having an empty string between commas as not permitted.
In 7.0, an empty string is still not permitted as 7.0 says:

A structure must have either a non-empty payload or at least 1 substructure.

Even in 5.5.1, there's no stated relationship between SPFX pieces and SURN pieces, so:

2 SPFX van
2 SURN Harten, Harte

is the same as

2 SPFX van, van
2 SURN Harten, Harte

Instead what you probably want is multiple NAME structures. For example, you could have

1 NAME Marianne /van Harten/
2 SPFX van
2 SURN Harten
1 NAME Marianne /Harten/
2 SURN Harten
1 NAME Marianne /Harte/
2 SURN Harte
1 NAME Marianne /van Harte/
2 SPFX van
2 SURN Harte

The above is valid in both 5.5.1 and 7.0.

[Norwegian-Sardines]

It is really too bad that v7 GEDCOM took this approach! We have used the comma separated list in v5.5.1 and before to support indexing various spellings of surnames and this new approach requires the person to have multiple NAME tags for cases where they never used the name spelled this way! This should be fixed, but can’t be fixed until v8.0 which means I will not support v7 in my software!

A bad choice with nothing good coming from it!

Actually the equivalent of
2 SURN Harten, Harte

in v5.5.1 is now

2 SURN Harten
2 SURN Harte

in v7.0

[tychonievich]

I agree that the example you give is correct. In particular, the specification says

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. It is permitted for the payload to contain information not present in any name piece substructure.

Thus, it is aligned with both the requirements and recommendations of 7.0 to have

1 NAME Marianne van /Harten/
2 SPFX van
2 SURN Harten
2 SURN Harte
2 SURN van Harte
2 SURN van Harten

It is even permitted, though not preferred, to add

2 SURN Something Unrelated

[albertemmerich]

I do not agree: neither SURN Harte nor SURN van Harte appears in the payload of NAME. Therefore the given example violates the recommendation of GEDCOM 7.0, however it is allowed.
And the recommendation makes sense: As only the NAME carries the data, and the PERSONAL_NAME_PIECES are optional (See 7.0 standard: "are provided optionally for systems that cannot operate effectively with less structured information") it is not recommended to put other data than already shown in NAME as payload to the substructure.
So to follow 7.0 please use the multiple NAME

1 NAME Marianne van /Harten/
1 NAME Marianne van /Harte/

may the PERSONAL_NAME_PIECES added.

[tychonievich]

I see "in some form, possibly adjusted" as allowing alternative spellings, but I understand why that's might not be a universal view given that we did not list spellings in the example adjustments.

[Norwegian-Sardines]

I do not agree: neither SURN Harte nor SURN van Harte appears in the payload of NAME. Therefore the given example violates the recommendation of GEDCOM 7.0, however it is allowed. And the recommendation makes sense: As only the NAME carries the data, and the PERSONAL_NAME_PIECES are optional (See 7.0 standard: "are provided optionally for systems that cannot operate effectively with less structured information") it is not recommended to put other data than already shown in NAME as payload to the substructure. So to follow 7.0 please use the multiple NAME

1 NAME Marianne van /Harten/
1 NAME Marianne van /Harte/

may the PERSONAL_NAME_PIECES added.

1. The individual was never know by the name "Marianne van Harte" (only by the surname "van Harten") so this violates the statement "Names of individuals are represented in the manner the name is normally spoken", therefore this would also be wrong based on the same spec!

2. The specification 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. It is permitted for the payload to contain information not present in any name piece substructure."

Based on (2) we must allow.

• The NAME tag to represent the name as used by the individual, which implies to me the "Display Name".
• The PERSONAL_NAME_PIECES (in this case SURN tag) to represent additional information (aka "auxiliary") about the name including other surnames associated with the displayed surname, examples gender specific surnames, alternate spellings, alternate groupings ("or the like").

If a receiving application does not want to support alternate spellings or use the SURN tag to organize ("index") the names of individuals based on spelling but rather the name an individual (who may not be able to read or write) spoke/used then they can ignore the SURN tag. They should never use the SURN tag to create a "display name" which is the job of the NAME tag!

NOTE: In GEDCOM v5.5.1 the individual pieces of the PERSONAL_NAME_PIECES differentiated the pieces into two groups.

1. "Non indexing name piece"
2. Regular name piece

We interpreted type (2) to be used, when present, as indexed values. So that when we list individuals by surname, the SURN tag would be used to ensure that the correct index value was used rather than the "spoken" value, which may or may not accurately reflect the true spelling of the name or the grouping value!

[tychonievich]

Discussed in steering committee

• Using separate NAME is preferred if the name forms are used by the person; multiple SURN are also permitted by the specification in this case.
• Using multiple SURN (and other name pieces) is preferred to present variations on the name that were not used for the person. Note that multiple SURN is also sometimes used to break multi-word surnames into parts, making some ambiguity in how multiple name parts are interpreted.
• Having SURN payloads that are not included in the NAME payload is not recommended (and is known to cause data loss with some applications), but is permitted.

[Norwegian-Sardines]

Can these concepts be added to the v7.1 specification, rather than FAQ, so readers and application programmers understand what they could be supporting if they wanted a more robust application.

[dthaler]

Discussion during Steering Committee meeting 9 SEP 2025:

• Adding these concepts to the spec could be done in 7.0, they wouldn't need to wait for 7.1
• We will check the 7.0 spec and add any recommendation that are not already present
• We believe the question has been answered, but the answer is spread across three responses, so needs a summary response to mark as answer.

[tychonievich]

Attempting to summarize the answers above:

1.  2 SPFX van, , van,
    2 SURN Harten, Harten, Harte, Harte

   is not permitted in 5.5.1 (empty tokens between or after commas was not allowed), and 5.5.1 did not say that lists in different name parts were synced.

2. The most direct parallel of comma-separated name parts in 5.5.1 is repeated name parts in 7.0; the following 5.5.1

   2 SURN Harten, Harte

   would most directly become the following 7.0

   2 SURN Harten
   2 SURN Harte

3. If the goal is to record that Marianne van Harten and Marianne Harten are both acceptable names, separate NAME structures are the cleanest way to do that (in both 5.5.1 and 7.0). Creating those as separate NAME may be interpreted to mean that both names are used by sources about the individual. If only one was used by sources then a single NAME with a variety of name part substructures may be preferable (such as SURN van Harten and SURN Harten and SPFX van), but that may still prevent some applications from finding the name Marianne Harten depending on how that application interprets searching and SPFX.

   An alternative to represent that Marianne Harten should be accessible in indexing but was not used by the individual could be to make a NAME Marianne Harten with TYPE OTHER and a descriptive NAME.TYPE.PHRASE like not used.

Some of these points will be added to the 5.5.1 to 7.0 conversion guide and possibly to other FAQs and/or the 7.0 spec.

If I have missed a point, please let me know.