Conversation
This puts PLAC and SPLAC side-by-side, like NOTE and SNOTE. That is not the only possibility, and alternative PRs with other designs are anticipated to allow better comparison of the options. This only addresses the record-vs-substucture topic. The additional substuctures that have also been considered for PLAC/_LOC/etc are prepared for by creating a `<<PLACE_DETIALS>>` production to be the home for such additions in a future PR.
|
|
||
| The `<<SHARED_PLACE_STRUCTURE>>` inside a `SHARED_PLACE_RECORD` points to larger jurisdictions that this place is a part of. | ||
| If a city is part of a county which is part of a state, the city's place record should point to the county's place record, not the states. | ||
| Multiple `<<SHARED_PLACE_STRUCTURE>>`s are permitted to support places within multiple hierarchies (for example, a church that's both within an ecclesiastical region and a political region). |
There was a problem hiding this comment.
I think we need a TYPE/KIND to distinguish ecclesiastical, political, etc. containment. The _LOC extension does this with HIERARCHICAL_RELATIONSHIP.
There was a problem hiding this comment.
The HIERARCHICAL_RELATIONSHIP is needed (per existing _LOC usage) inside a "shared place structure" within a SHARED_PLACE_RECORD, but not from within a PLACE_REFERENCE since the latter is not a containment relationship. This suggests that using <<SHARED_PLACE_STRUCTURE>> in both places may not be appropriate.
| A `voidPtr` and `PHRASE` can be used to describe places not referenced by any `SPLAC` record, but so can a `PLAC` structure. Using a `voidPtr` with `SPLAC` is not recommended. | ||
|
|
||
| :::example | ||
| The following both indicate that a birth happened "at home" with no additional details on where that was. The second version is preferred; the first should not be used. |
There was a problem hiding this comment.
I'm less certain that the second version is preferred, since HEAD.PLAC.FORM would apply in the second version, where "at home" would then be labeled a "city" in UI. So we should discuss more.
I'd also ask the question: what is the meaning of HEAD.PLAC.FORM if only SPLAC is used everywhere? If none, then perhaps we need a sentence saying not to use HEAD.PLAC.FORM in that case.
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
2 participants
Conversation draft of adding place records to 7.1
This puts PLAC and SPLAC side-by-side, like NOTE and SNOTE. That is not the only possibility, and alternative PRs with other designs are anticipated to allow better comparison of the options.
This only addresses the record-vs-substucture topic. The additional substuctures that have also been considered for location records (for example, see GEDCOM-L's _LOC extension) would presumably be added to the new
<<PLACE_DETIALS>>production in a future PR if we decide that this organization is the right approach.