Notes from shared places open meeting 2025-05-27

[tychonievich]

Call time: 2025-05-27 16:00Z to 2025-05-27 17:08Z

Attending: 17 (5 are members of steering committee, 12 are not; 1 left half-way through). Because I did not ask permission to share names in these notes, I will identify speakers using anonymous IDs S1, S2, and so on, allocated in the order they appear in these notes.

• Overview of previous meetings and issues (see REMINDER: Zoom Meeting: Discuss extending SPLAC to include ADDR and PLAC #538 for previous meeting, Extending SPLAC to include ADDR and PLAC? #536 for recent issue)

  • Review of 7.0 extension vs 7.1 vs 8.0 decision point

    • S1: because big companies are still working on v7, we should not talk about v8 until they have that implemented
    • GEDCOM-L: v8 so we don't have to implement it twice

  • Within 7.0 extension / 7.1, two proposals

    • PLAC.SPLAC (Adding SPLAC under PLAC #527)
      • GEDCOM-L prefers because it helps map between PLAC and SPLAC, making merges simpler
    • PLAC beside SPLAC (Adding SPLAC beside PLAC #520)

  • Recorded place name vs canonical place -- maybe add a PHRASE to PLAC/SPLAC/_LOC?

• S2: use PLAC payloads as the "pointer" value that cross-references to _LOC
  e.g.

  0 INDI
  1 DEAT
  2 PLAC Chicago, Cook, Illinois, USA
  0 _LOC Chicago, Cook, Illinois, USA
  1 MAP
  2 LATI ...
  2 LONG ...
  1 NOTE ...
  1 EVEN ...

  This could be done as 7.1. Try to break nothing and make as simple as possible and make it easy to ignore everything. This has been needed since the beginning, and this is the simplest way to do that.

• S3: the SPLAC proposals are great, but trying to go halfway is a nightmare to manage. Switch cleanly to new model. NOTE/SNOTE is already more complicated than desired. What's the rush? Many programs already handle what we have now.

  • S4: agree
  • S5: agree
  • Question does anyone want us to do something sooner than 8?
    • S5: let's standardized _LOC
    • S6: but that's something in 7.1
    • S2: don't move on to 8 until large players adopt 7

• S5: see https://github.com/FamilySearch/GEDCOM/blob/190beea55fbdf08e1a35519fd235a5ff33c68634/specification/gedcom-6-appendix-examples.md

• S2: a hierarchy of places will be hard to make work for multiple programs. Leaving it as a list lets programmers implement it however they want, while keeping the higher and lower level options.

  • S3: there is some value in being able to rank places by fixed level (i.e. line up all by county), so they should all be the same lists

  • S4: we should not program a hierarchy, let the users pick it. Place records are needed and would prefer pointers to comma-separated strings, which is a breaking change, but since everyone would need to have pointer-like implementation that should work.

    • S2: the pointers would be nicer if they were in existing code, but the strings avoid the breaking change.
    • S4: we use the PLAC names as the pointer-like keys of the place record now. It would be no problem at all to implement this in 7.1.

• S7: we use standardized places, but we don't store most of that in our database (it's in a separate place authority repository) so it doesn't matter.

• S2: The big players don't appear to support user-defined place information.

• S6: we have comments about how we could do 7.1 if we wanted to, but no one saying we should do it in 7.1. Proposal: leave it as extensions for v7, and don't standardize anything until v8

  • (a few say agree, none say disagree)

• S8: should we deprecate HEAD.PLAC.FORM?

  • S5: we should require them to avoid the chaos.
  • S8: how do we merge them if they disagree.
  • S3: we should fix some things in places (country, city) while letting others vary. Keep the keys that are used in geolocation APIs easy to find.
    • S6: some places don't have a country (e.g. "at sea"); also, what is a "country" varies by time so let the user pick it
    • S8: is Taiwan a country? different people disagree
    • S4: the UK is a country made up of 4 other countries
  • S3: geoname database tries to standardize coding; can we re-use what they do? or align to another open standard?
    • S4: if we force users to standardize, they will find a way around it
    • S3: but we already standardize data -- that's what GEDCOM is
    • S4: but we can't force them to do what we want
    • S3: but if we have some forced HEAD.PLAC.FORM then it makes sharing easier, and apps can implement it as they wish
  • S6: we can merge with HEAD.PLAC.FORM by converting to PLAC.FORM and then merge
  • S2: we have a problem when jurisdictions come and go, because it creates blanks in the hierarchies
    • This is partially addressed in the spec today: https://gedcom.io/specifications/FamilySearchGEDCOMv7.html#FORM
    • S6: but there are applications that ignore the spec on this
  • S2: what about adding things like cemetery names?
    • S6: the spec today handles that easily, but some applications don't
  • S3: PLAC.FORM is the main need for interoperability
  • S6: a problem with PLAC.FORM is that it is language-specific, which makes merging hard
    • S3: this is a problem in the data; translation is doable, and some things don't translate
    • S9: shared examples of places with very different structures than one another
    • S3: PLAC.FORM is not mandatory and some users don't want to use it
  • S5: I use two programs, one has no structure and the other has jurisdictions. If HEAD.PLAC.FORM exists then merging files involoves making a superset of the jurisdiction sets
  • S4: we don't use HEAD.PLAC.FORM at all and almost don't use PLAC.FORM, and it hasn't been a problem. We merge people and events and let users handle conflicts in places when merging
  • S3: users often ask how many people/events are in a given place, and PLAC.FORM enables that

Summary:

• No advocates for shared places in 7.1, though some comments on what is better or worse if 7.1 shared places were added. Lacking advocates, we plan to wait for 8.0 to add shared places. Extension records can continue to be used by applications desiring shared places until that time.
• There are many views about PLAC.FORM, ranging from banning it to requiring it to leaving it as is, with no consensus on changes to make. Lacking consensus, it will likely remain as-is for now.

[Norwegian-Sardines]

It was really nice that you had a meeting about SPLAC without me when I specifically had input but could not meet until I returned from holiday!

[tychonievich]

Sorry you couldn't make it! Finding meeting times that work for all schedules is challenging. We welcome your input here, and may have additional meetings in the future.

[Norwegian-Sardines]

I’m on the road and using my phone. we need a specific place for discussion of PLAC, rather than a dozen different threads. Start a list of the various solutions, a place for pro/con of each concept, answers to questions, and refinement of each solution! Do we have specific notes from the meeting for my review?

[tychonievich]

The notes from today's meeting are the first post in this discussion.

[Norwegian-Sardines]

You indicated you left early, then these are complete?

[tychonievich]

They are complete, yes

[Norwegian-Sardines]

Question: What is the value to an application for the inclusion of HEAD.PLAC.FORM when importing?

A1:
Programs importing a GEDCOM into a new database could use the HEAD.PLAC.FORM to “prime” their data entry screen labels with these divisions (e.g. country, state, county, city) so that any new place data follows the same pattern.

A2:
Applications with a predefined place hierarchy that conflicts with the imported GEDCOM would have issues particularly if data already exists that conflicts with the imported HEAD.PLAC.FORM?

Comment:
The problems noted in A2 could be manually resolved in some cases, I think automation of resolution may be out of the scope of the application! For example: what if the imported GEDCOM comes from a country that does not use the same terms for its divisions as the resident data, or the divisions have been translated into the two different languages?

Conclusion:
I don’t see an immediate need for the HEAD.PLAC.FORM

[Norwegian-Sardines]

Question:
How is the answer to the statement “S2: we have a problem when jurisdictions come and go, because it creates blanks in the hierarchies”, valuable in reality.

A:
The answer was to look at https://gedcom.io/specifications/FamilySearchGEDCOMv7.html#FORM. This is probably the worst example for using the PLAC.FORM value!

The following represents Baltimore, a city that is not within a county.

2 PLAC Baltimore, , Maryland, USA
3 FORM City, County, State, Country

1. Baltimore before 1851 did reside within a county and was only an independent city after 1851.
2. If I was using the PLAC.FORM for an event after 1851 I would not set the FORM to this value I would override the HEAD.PLAC.FORM (probably set to City, County, State, Country) by removing “County” from the list, removing the need for the blank entry:

2 PLAC Baltimore, Maryland, USA
3 FORM City, State, Country

3. Someone could be born in 1825 in Baltimore and died in 1890 in Baltimore would have two different entries:

1 BIRT
2 DATE 1825 
2 PLAC Baltimore, Baltimore, Maryland, USA
3 FORM City, County, State, Country

1 DEAT
2 DATE 1890 
2 PLAC Baltimore, Maryland, USA
3 FORM City, State, Country

[Norwegian-Sardines]

Statement:
S3: PLAC.FORM is the main need for interoperability

Comment:
By “interoperability” do you mean, merging into a Place/Location Database? The merging of two GEDCOMs with different place hierarchies does not necessarily cause issues. Since most genealogy applications in use today do not support the use of PLAC.FORM how will requiring the value enhance the merging of two GEDCOM files. Place names change, hierarchy names change, even the physical location of a place can change over time.

---

Statement:
S3: users often ask how many people/events are in a given place, and PLAC.FORM enables that

Comment:
Not really! A PLAC.FORM tag has no bearing on a simple query when a PLAC tag “CONTAINS” a value (for example: “Baltimore” or “Illinois”) it is up to the data entry people to provide the application with data. If they don’t identify that the state of Illinois was where a person was born, then the query will not find that person! But if they did not enter the state in the BIRT.PLAC, chances are they did not know the state, only the country.

Conclusion:
I'm not convinced that an immediate need exists for either the HEAD.PLAC.FORM or the fact.PLAC.FORM in a GEDCOM transmission.