REMINDER: Zoom Meeting: Discuss extending SPLAC to include ADDR and PLAC

[clarkegj]

September 10th 9:30 am Mountain Time
All interested parties are invited!
https://churchofjesuschrist.zoom.us/j/93447833965?pwd=NEzPe81iBm8jAbnygshT53sWRYZiYW.1

This may include discussions:
Planning for 7.1 and/or 8.0 next #519
PLAC tag and about extensions #530
Extending SPLAC to include ADDR and PLAC? #536

Notes from Discussion in GEDCOM Steering Committee 20 AUG 2024:
• The committee discussed examples like @Norwegian-Sardines mentioned above where PLAC and SPLAC could get out of sync in terms of the hierarchy.
• If you just put the lowest level in the PLAC payload then this problem doesn't occur, but it is not backwards compatible without data loss.
• If information is in both places for backwards compatibility, there is always the danger of being out of sync with each other. One could perhaps declare a precedence between the two as to which one wins, but it's unclear if that's helpful.
• If information is not in both places, one loses backwards compatibility with apps/websites that don't yet support the new structure.
• We want this to be a topic of discussion in a public meeting that will be scheduled before making any decisions. Watch the discussion board for details. The purpose of these draft PRs is to generate such discussion.

[tychonievich]

Notes from the zoom call:

• SPLAC/LOC/etc has advantage of each place being able to have a superior (i.e. containing) place, but a place may have several of these, with time windows for each. Example: a single town that was in the Austo-Hungarian empire, and at another time Hungary, and at another time Serbia. To record that would need date period for each, but that won't always be available. In particular, a historical record often has only a snapshot of that place hierarchy, and that should be recorded as-is. But there also might be extra information about the place that should also be stored.
  • summary: need dates to make the hierarchy correct, but dates may not be available and/or easy to implement
• Alternative: could have a separate database of places, and the GEDCOM file only indicates the identifier in that database; this would avoid replicating the data in each data GEDCOM file.
  • summary: instead of putting the hierarchy in the file, put it elsewhere with an identifier
• Example: English county system restructured 1888, and several times after that; old counties still exist in some ways but so are new, with different roles; not easily put in a hierarchy
• Application with hierarchical, date-sensitive location records exist, and allow users to pick how they use it. Some want the most current name of the place, others want the name that was used at the time of the historical event. Names of places should have dates, as should hierarchical relationships. GEDCOM-L's _LOC handles all of this: users get to choose to use a database ID and/or hierarchical records with current names and/or hierarchical records with historical names. Databases don't cover every case users care about.
• Would be good to have record of what the record says (researcher perspective), and what we think that means (conclusion perspective). Data should include both of those, not just one or the other. Hence, should be (at least) two places to store info: what I found and what I conclude (applies to places and other parts of the file format too).
• Example of cities physically moving to new coordinates.
• Hierarchical location management might be wrong of differ between GEDCOM files; the relationship between places should be external to the file. The _LOC/SPLAC should be used for additional information (coordinates, notes, sources), not necessarily for common information.
• Addresses -- many users want coordinates of specific buildings, which is commonly handled with ADDR (though PLAC does allow that too in principle). Address management is also a topic of interest.
• While we can cite external databases, some users have specific information about all the farms in a village or the like, which are not found in external databases. We should support the references, but should also allow the user to enter their own information as well. Creating a system for extending databases is complicated (logistically, dealing with disagreements, etc) so it's useful to allow users to enter that information in their file.
• People who catalog historical records often just copy what they see, without considering the issues we're discussing. That impacts us because records need to connect to data.
• Topics for future meetings:
  • address management -- changes, different standards, etc
  • where to put the information, whichever version of new information we add (beside or beneath in 7.1 or replace in 8.0)

The discussion did not reach any conclusions, but shared several perspectives. We plan to revisit this in the future. Please put further comments in #536 so we can review before we meet again. We hope to see pull requests exploring a few of these options so we have something more concrete to discuss. We will tentatively meet again in roughly 1 month.

[mother10]

Some remarks according to the zoom call of sept 10:

Great to be able to see everyone now. The screennames (below someone's video) were helpfull, but I have a question: can we have AND the "nick" we use in these forums AND someones real name (if they differ) (maybe only firstname if someone rather wants that) I had no idea who some of you were :) :) :) Couldnot always make the link so to say. And as this was an open meeting, people who are not in your regular meetings, might have the same problem. You all know eachother, but we dont. :) :)

Its a pity we couldnot see everyone at the same time, only a few at the top, including the one speaking. Would it be possible to see more people?

As I am partly deaf (40-50%) I had real trouble hearing what people said, even with my volume turned up high. So Luthers typing was very helpfull. Have to figure out if I can find a solution for that on my side. Otherwise its difficult for me to react.

The meeting had a starttime, but I was a bit surprised about the length, maybe mention an endtime or length too?

Tineke/Mother10