Implementing SPLAC records in future standard

[albertemmerich]

Gedcom-L had again a discussion how to handle places in future standards.
We recommend to replace the PLAC tag at all, and have a solution like

2 SPLAC @P1@
3 PNAME <local name of place>

PNAME is given to have the name of the location as given in the source for the this occurance, or as the user wants it to see it (may differ according to time, or source, or user for same @P1@!).

No more subtags to SPLAC: All other information is given by the SPLAC record @P1@, as: names of the place (may be several depending on time and language), type of place (including buildings, churches, cemeteries, cities, counties, states, countries), jurisdictions and the hierarchy, postal codes, GPS coordinates, ids in external systems, .... By this the multiple repetition of these data within the file is eliminated, which we have in 7.0 by the subtags of PLAC.

As this is a breaking change, we need standard version 8.x for it.

[Norwegian-Sardines]

This is probably a language or translation issue, but I don't understand this statement!

We recommend to replace the PLAC tag at all, and ...

I believe that GEDCOM-L is suggesting the "deprecation" of the PLAC tag and replacing it with SPLAC and using PNAME as either,

1. "Observed Place" as entered in the "Source Artifact" for the associated fact.
2. "Current Place Description" for the associated fact (transmitted place description concluded by submitter).

GEDCOM-L would also suggest that "No additional subtags to SPLAC, therefore deprecating the entire PLACE_STRUCTURE as defined in the current GEDCOM Standard and replacing it with a simple:

2 SPLAC @P1@
3 PNAME <local name of place>

I'm not sure what "local name of place" references, a definition here would be warranted! I would see this as one of the two options as noted above and as previously defined in my proposal of 30 SEP 2024.

Can I assume that the PLACE_RECORD (SPLAC) design would follow closely (with some minor changes) to my proposal of 30 SEP 2024 #536 (comment), which I've updated a little based on some comments but not uploaded.

I agree that the GEDCOM-L proposal (deprecating the PLACE_STRUCTURE) would be a breaking change and require that the change occur no sooner than v8.0 of GEDCOM.

I'm not at all privy to the timeline of v8 GEDCOM and in my mind this version may never occur and since few (if any) applications have embraced the entire breadth v7 of GEDCOM, therefore a shared place record may never get introduced or implemented. Maybe v7.1 is so close (again the timeline of this version is outside my purview) that an intermediary concept of leaving the PLACE_STRUCTURE intact with a minor update to include an SPLAC subtag to PLAC can not be implemented within its desired timeline.

Therefore, without additional knowledge, I can't comment additionally on the GEDCOM-L proposal.

[dthaler]

Discussion in GEDCOM Steering Committee 3 DEC 2024:

If the record records a place like "Hamburg" it may be ambiguous as to what the parent place is, so could be either of multiple place records. The above recommendation does not solve this. What about

2 PNAME <local name of place>
3 SPLAC @P1@
3 SPLAC @P2@

to mean that one of the records is right but it is not certain which one, and they are listed in order of preference?

Also, it was observed that FORM would be unnecessary in any of the proposals in this discussion that have no PLAC structure.

Question: is having a payload for PNAME required or optional? An argument for optional is like DATE.PHRASE is optional where the text in the source document can be included but often only the standardized form is used in GEDCOM. A reason for a payload being present (but not required) might be to indicate which of multiple names in an SPLAC record is the one to use in reports; another reason is to record what the source record stated literally. We could not think of any reason to require a payload and GEDCOM-L proposed it be optional.

[Norwegian-Sardines]

If the record records a place like "Hamburg" it may be ambiguous as to what the parent place is, so could be either of multiple place records. The above recommendation does not solve this.

This is always an issue when recording the "Observed Place" found in the "Source Artifact". So the question becomes, Is a transmission a conclusion by the submitter or is it a postulation by the submitter? If it is the former then a second SPLAC is not warranted, but if it is the later then some form of "CERTAINTY_ASSESSMENT" would be needed.

I run into this often when reading locally created "Source Artifacts" from for example a church. They may provide a reference to a place or person that locally has exacting reference but in a larger context may need to be interpreted. At present I don't have a good way to identify when I have made a decision that based on my local knowledge other than by including a NOTE in the PLAC or NAME structures!

I would think adding a NOTE to the structure would help but not solve this question!

[Norwegian-Sardines]

Also, it was observed that FORM would be unnecessary in any of the proposals in this discussion that have no PLAC structure.

In my proposal a PLAC does have comma separated structure, and in my personal opinion PLAC.FORM is at best messy and at worse of little value, because of the unlimited list of place forms that could be used when we consider language, local and time. For example every country has subdivisions that are named differently and over time even within these countries the subdivisions have changed or been call by different names depending on the superior division! I have not encountered an application that uses FORM in a sufficient manor, but I have not used every application!