There is a need for an entity for an individual location. This will allow descriptive information, events, pictures, and anything else pertaining to a location to be defined together.
A number of issues related to Locations are discussed here: message/view/BG+Data+Model+Discussion/29953155
Objective vs. Subjective Location Entities
Different points of view:
1. Objective places only: Subjective or free-form location entries will only cause problems and should not be included in BetterGEDCOM.
2. Subjective places only: All places must be free-form and not tied to external geographic mapping or naming systems or conventions.
- This approach assumes all locations can be mapped objectively and without ambiguity.
3. Subjective places with objective geographic naming/mapping system references: Place names in BetterGEDCOM file format should be free-form and not be subjected to any external naming rules but should also include extensions within the data stream allowing reference to different geographic naming/mapping systems and information needed to map within those systems.
- not advocated by anyone to date
- This approach provides free-form flexibility for users while also preserving data for use of geographic information systems.
Location entries need to accommodate modifying adjectives, such as:
- either/or ??
- probably/possibly? (not sure about this)
(Locations may have events. These define something that happens regarding this location at a specific date and time. The "birth" and "death" of locations should be noted as event for the location, although we may want to name them something else, e.g. "Formed", "Built", "Established", "Dissolved", "Burnt Down", "Parceled". This is useful for recording farm histories passed down and split up through inheritance.) This concept is at the least very open to question.
Location Time & Date
(Every location has both a time and date element. This is not to say that these two together define an objective, absolute location.)
GEDCOM and Places
The existing GEDCOM identifier for a place has unlimited levels separated by commas, with a limit of 120 characters; it also supports naming the jurisdictional entity titles with the PLAC.FORM element. A global default place hierarchy can be defined in the HEADER, which is overridden by a local PLAC.FORM entry. It is incorrectly assumed that GEDOM only supports 4 levels : (1) city, (2) county, (3) state, (4) country. Two more lower levels are needed prior to the city. (1) location within site, and (2) site. The site would be the specific place of interest within the city. It can, for example, be an address or the name of a building or a park or a cemetery. The location within site would be used to subdivide sites, e.g. bedroom, Apartment B210, or Section 3; Row 4; Plot 40.
Therefore, an entire location might be something like:
where two commas indicate a missing placeholder (in this case, the county). [Missing placeholders are not relevant to BetterGEDCOM.]
Missing placeholders are not needed for leading levels. e.g. if the first 5 levels are left out, then no commas are needed, e.g.:
- Section 3; Row 4; Plot 40, Silver Plains Cemetery, Winnipeg,, Manitoba, Canada