diff --git a/specification/gedcom-2-data-types.md b/specification/gedcom-2-data-types.md index be8641a5..73b52db2 100644 --- a/specification/gedcom-2-data-types.md +++ b/specification/gedcom-2-data-types.md @@ -30,6 +30,18 @@ Negative integers are not supported by this specification. The URI for the `Integer` data type is `xsd:nonNegativeInteger`. +## Decimal + +A decimal is a non-empty sequence of ASCII decimal digits that may include an ASCII period (".") to indicate the decimal point. It represents a rational number in base-10 and can have any number of digits after the decimal point. Leading zeros have no semantic meaning and should be omitted unless immediately preceding the decimal point. + +```abnf +Decimal = 1*DIGIT [ "." 1*DIGIT ] +``` + +Negative Decimal numbers are not supported by this specification. + +The URI for the `Decimal` data type is `xsd:decimal`. + ## Enumeration An enumeration is a selection from a set of options. diff --git a/specification/gedcom-3-structures-1-organization.md b/specification/gedcom-3-structures-1-organization.md index 43fda974..ce52cacf 100644 --- a/specification/gedcom-3-structures-1-organization.md +++ b/specification/gedcom-3-structures-1-organization.md @@ -122,6 +122,8 @@ n <> {1:1} | n <> {1:1} | +n <> {1:1} +| n <> {1:1} ] ``` @@ -153,7 +155,7 @@ n HEAD {1:1} g7:HEAD +1 SUBM @@ {0:1} g7:SUBM +1 COPR {0:1} g7:COPR +1 LANG {0:1} g7:HEAD-LANG - +1 PLAC {0:1} g7:HEAD-PLAC + +1 PLAC {1:1} g7:HEAD-PLAC +2 FORM {1:1} g7:HEAD-PLAC-FORM +1 <> {0:1} ``` @@ -169,6 +171,20 @@ A few substructures of note: - `HEAD`.`SOUR`.`DATA` describes a larger database this data is extracted from. - `LANG` and `PLAC` give a default value for the rest of the document. +### New for 7.1: +- `PLAC` now is {1:1} so obligatory. +- `FORM` now has `g7:HEAD-PLAC-FORM71` which is defined as follows: +The ` ` always consists of the following string of jurisdictions (smallest to largest: + **`LOCATION, ZIPCODE, VILLAGE, CITY, CODEINSEE, DISTRICT, PROVINCE, COUNTY, STATE, COUNTRY, SEA, EARTH`** + These are in fact the original jurisdictions from GEDCOM7 with a few added. With this list, older GEDCOM files can be converted, by comparing their `PLAC.FORM's` with this list. + When GEDCOM files have other jurisdictions, which they often have, the jurisdiction in this list, that comes closest has to be taken. After that it can be further subdivided into the jurisdiction found in the original file that is converted, by adding the **GOV** number as explained for the TAG `GOVTYP` in the `PERIOD_STRUCTURE`. + **See the examples for how this will look and has to be done** as it is possible to also add descriptive text, to make it more visible for users. + +::: +Example: +- In the original file the jurisdiction is "Kingdom", then the one coming closest is "COUNTRY", and we add the GOV number 31 to denote it is a kingdom. +- In the original file the jurisdiction is cemetary, then we use the general (smallest) `LOCATION` from the above list, and we add the GOV number 89 to make it a cemetary. +::: ### Records @@ -400,19 +416,170 @@ A `SHARED_NOTE_RECORD` may contain a pointer to a `SOURCE_RECORD` and vice versa ```gedstruct n @XREF:SPLAC@ SPLAC {1:1} g71:record-SPLAC - +1 TYPE {0:1} g71:SPLAC-TYPE +1 LANG {0:1} g7:LANG - +1 TRAN {0:M} g71:TRAN - +2 LANG {0:1} g7:LANG - <> {1:1} - <> {0:M} g71:SPLAC + +1 TYPE {1:1} g71:SPLAC-TYPE + +2 HREL {0:M} g71:SPLAC-HREL + +3 GOVTYP {0:1} + +4 TEXT {0:1} g71:SPLAC-TEXT + +1 <> {1:M} + +1 <> {0:M} + +1 <> {0:M} + +1 <> {1:1} + +1 <> {1:1} ``` A descriptor of a single place, location, or jurisdiction. +This record describes a location where an event occurred, including its name, geographical position, and historical parent jurisdictions across various timeframes. Each timeframe (`PERIOD`) is detailed with its corresponding administrative hierarchy, reflecting the changes in jurisdiction, boundaries, names or geopolitical status over time. The record allows for the capture of information relevant to the specific date of an event. + +As the `SPLAC`Record now will contain a lot of information, coming from (possibly) many users, it might be a good idea to allow the adding of **`SUBM`** on some places (as is already done now for the `TYPE`of the `PERIOD`structure) That way information can be traced back. + +Shared place records offer more flexibility than place structures do. A PLAC can be replaced by an SPLAC without loss of information by making one SPLAC record for each non-empty string in the PLAC's payload and linking them together using the SPLAC's SHARED_PLACE_STRUCTUREs. How to copy information into the new chain of SPLAC records is described at the `PERIOD_STRUCTURE`. + +The `PERIOD_STRUCTURE`consists of the folowing parts: +- **The `` payload** of the `SPLAC`, is the **default name** of the location, that will be used for this `SPLAC`. For instance in a "Treeview", or user-output, or when a user searches for a place to enter for an event. The only time a user should see another name, is when he/she (partly) typed one of the Names, inside a `PERIOD` of this place. + +::: +Example: When, for a certain date of an event, a user types "Amster" the program might show him "Amsterdam", but when he types "Amstelle", the program will show him "Amstelledamme" as that was the name of Amsterdam around 1275, and valid on the date of the event the user is entering. +**In both cases** the user gets **the same SPLAC**. This way there is less clutter in the GEDCOM, and there are less entrypoints to maintain. +::: + +- **LANG** only defines the language of the TEXT payload (which is the default NAME of this `SPLAC`). +If an `SPLAC` has more Names with Translations for those Names, they must all be inside the `PERIOD_STRUCTURE`(s). +This way, "links" from **inside other SPLAC's, or from events**, always have 1 entry point for whatever information might be inside any `PERIOD` of this `SPLAC`. +As the `PERIOD's` inside an `SPLAC` always have a DATE-period, a program can determine, coming from an event on a certain Date (or in a certain timeframe), which `PERIOD` of the `SPLAC` it should pick its information from. + +- **TYPE** The `TYPE` of the `SPLAC`. This is meant to be the types that now are in the`PLAC` or `PLAC.FORM` of GEDCOM7, so in fact **the original jurisdictions**. These jurisdictions are now defined in the enumset `SPLAC-TYPE`. +`TYPE`can be combined with the subtags `HREL`, `GOVTYP`and `TEXT` that follow it. (see **"TYPE, HREL, GOVTYP and TEXT"** for an explanation.) + +- **HREL** A `TYPE` that is the `HIERARCHICAL_RELATIONSHIP` of the `SPLAC`. +This type describes the structured relationships between entities, where one holds a position of authority or influence over another. This includes political, administrative, religious, geographical, cultural, or other hierarchical associations, such as between nations, regions, organizations, or social groups. +So the relationship of an `SPLAC`can be: political (administrative), religious, geographical or cultural. See `g71:SPLAC-HREL`. +`HREL`can be combined with the subtags `TYPE`, `GOVTYP`and `TEXT` that are near it. (see **"TYPE, HREL, GOVTYP and TEXT"** for an explanation.) `HREL` is defined directly after `TYPE` because both have an {1:1}, so both are obligatory and should always be present. + +- **GOVTYP** (which is a `TYPE`) Defined in GEDCOM_L as: {Size=1:3} In GEDCOM_L it is called `` and it is defined there as follows: +An integer positive number as defined in the GOV system. The definition in the GOV system http://gov.genealogy.net/type/list is binding for the interpretation of this line and allows an interpretation of the superior line 1 TYPE for all languages stored in the GOV system. The multilingual RDF file with the definitions of the object types of the GOV system is also available for this purpose https://gov.genealogy.net/types.owl . +The enumeration: `g71:SPLAC-TYPE` only defines a subset of the GEDCOM_L `` list, namely those that are the most common jurisdictions in GEDCOM7. To use the other `` values, they have to be put behind the general `g71:SPLAC-TYPE` **"LOCATION"**, to further specify `LOCATION`. This way all numbers from the around 280 GOV numbers can be used. +We strongly encourage to always have a `GOVTYP` too. (See the above mentioned list) + +Also see the examples in the example chapter. +`GOVTYP`can be combined with the subtags `HREL`, `TYPE`and `TEXT` that are above and below. (see **"TYPE, HREL, GOVTYP and TEXT"** for an explanation.) + +- **TEXT** (`g71:SPLAC-TEXT`) Optional. This is either the written "Name" of the **GOVTYP**, or a free user text. If it is present it must always be put at the end of the line, separated from it by a comma. (see **"TYPE, HREL, GOVTYP and TEXT"** for a definition and explanation.) + +- **TYPE, HREL, GOVTYP and TEXT**, which are in fact 4 separate lines, have to be combined to 1 line, for better readability. Combining is only possible when the first 3 lines both are a **`"TYPE"`** as in this case, followed by a `TEXT`of type `g71:SPLAC-TEXT`. + +:::Example: +**` 1 TYPE COUNTRY, 7, POLI, Federal State`** +This means it is the `SPLAC-TYPE` **COUNTRY**, combined with the `` **7, which is Federal state**, and this `SPLAC` is in an political hierarchy. +Each parameter is separated from the previous one by a comma. The explaining text of the number is put at the end of the line. + +**` 1 TYPE PROVINCE, 6, RELI, Diocese`** +This means it is the `SPLAC-TYPE` **PROVINCE**, combined with the `` **6, which is a Diocese** and this `SPLAC` is in a religious hierarchy. +::: + +- **`<>`** This reflects the historical changes in governance, boundaries, or place names in a certain timeframe. + + +**The first `PERIOD` inside an `SPLAC`**, always serves as the default `PERIOD`. Information from this `PERIOD` has to be used if another `PERIOD` in this same `SPLAC` lacks that information. +Also if a user enters a place that has no `SPLAC` yet, that `SPLAC` will get a default `PERIOD` with a DATE period filled in **From 0** (as Dates cannot be empty) + +:::Example: +**the Places location(s)**. If inside a `PERIOD` where there is no other location given (meaning for this period the place has not "moved", according to the first `PERIOD`), the program should use the Location given in the first (default) `PERIOD`. But if there IS a location inside a `PERIOD` (meaning the SPLAC has "moved" to another location inside this period of time), that location is valid for that period. So a program can pick the correct location depending on **the date ( or dateframe) of the event pointing to this SPLAC**. + +**The Place Name(s)**. If inside a `PERIOD` no other Name(s) are mentioned, the Name as it is specified in the first `PERIOD` is valid. But if there **IS** a name inside a `PERIOD`, that name is valid for that period. So a program can pick the correct Name depending on the date (or dateframe) of the event pointing to this `SPLAC`. +Same for other information inside `PERIOD's`. +See also the extended examples in the examples chapter. +::: + +#### `PERIOD_STRUCTURE` := + +```gedstruct +n PERIOD + +1 TYPE {1:1} g71:DATA-INFO-TYPE + +2 TYPE {1:1} g71:SPLAC-TYPE + +3 GOVTYP {0:1} + +4 TEXT {0:1} + +2 SUBM @@ {0:1} g7:SUBM + +2 <> {0:M} + +2 <> {0:M} + +1 DATE {0:1} g71:PERIOD-DATE + +1 <> {0:M} + +1 <> {1:1} + +1 DMGD {0:M} g71:DEMOGRAPHICAL-DATA + +2 TYPE {1:1} + +2 DATE {0:1} + +2 <> {0:M} + +1 AIDN {0:M} + +2 TYPE {1:1} + +2 DATE {0:1} + +1 <> {0:M} g71:SPLAC + +1 <> {0:M} + +1 <> {0:M} +``` + +A `PERIOD_STRUCTURE` reflects the historical changes in governance, boundaries, or place names in a certain timeframe. + +It will include: + +- **The TEXT payload** is the **(default) Date period** of this `PERIOD` (It can be empty, but only for the default `PERIOD`, which is the first, `PERIOD`. Information inside a `PERIOD` will be valid only for this `PERIOD`. +If the `DATE` period is not known, it will be assumed to be from far in the past till present day, presented as **`FROM 0`**. + +- **`TYPE`** The `DATA-INFO-TYPE` of this `PERIOD`. There are (for now) 3 types possible: +: **SOURCE** = from the researcher perspective, +: **USER** = from the conclusion perspective, so after a user deducts and concludes to other results as were found in the records. +: **OWN** = as in the problem where information is coming only from a user. Like for instance a users private information about FARMS etc. + +- **`GOVTYP`** Defined as `` in GEDCOM_L as := {Size=1:3} An integer positive number as defined in the GOV system. The definition in the GOV system http://gov.genealogy.net/type/list is binding for the interpretation of this line and allows an interpretation of the superior line **`2 TYPE`** for all languages stored in the GOV system. The multilingual RDF file with the definitions of the object types of the GOV system is also available for this purpose https://gov.genealogy.net/types.owl . + +- **`SUBM`** Especially in case the `TYPE` is **`OWN`**, meaning this PERIOD contains information completely coming from own work of the user / submitter, and not from any public record. In that case `SUBM`can be used to point to that user. + +- **`DATE`**: A specific time range that ties the location, Name(s), parent jurisdictions, and all other information in this `PERIOD` to this time frame. For a `PERIOD_STRUCTURE` it can either be a `` or a ``. + +- **`<>`**, gives the **Location name**. The name of the location, mentioned in an event, as it was known in the timeframe of this `PERIOD`. + +- **`<>`** : Gives the **Location position**. This can be the location (latitude and longitude), or a `GOVID` number (as with GEDCOM_L), a PostalCode, an address, a Maidenhead number, or any other means of locating, defining the `LOCATION` of the place where the event in this time frame happened. + +- **`DMGD`**: Defined as `` in GEDCOM_L as: := {Size=1:120} A number of objects, gathered during a Census, e.g. the count of households. + +- **`TYPE`**: Defined as `` in GEDCOM_L as: := {Size=1:35} Type of the demographic data for a place, e.g. **`POPULATION, HOUSEHOLD, RESIDENT`**. + +- **`AIDN`**: Defined as `` in GEDCOM_L as: := {Size=1:35} Identifier for a location with the intention of an administrative authority, e.g. community identifier. +**The official municipality key (AGS)**, also known as the municipality code (**GKZ**), is an eight digit code that uniquely identifies politically autonomous municipalities or municipality-free areas in Germany." +[Official municipality key (AGS) - IOER Monitor](https://www.ioer-monitor.de/en/methodology/glossary/o/official-municipality-key-ags/#:~:text=The%20official%20municipality%20key%20(AGS,municipality%2Dfree%20areas%20in%20Germany). + +::: +Extra information: +In Germany, the AIDN (Administrative Identifier Number) typically refers to a code that identifies administrative entities such as cities, municipalities, or institutions. This is part of Germany's administrative organization for civil records and vital event registrations. + +Use of Administrative Location Identifiers in Other Countries: +Similar systems exist in other countries, where locations or civil registration offices have their own unique codes, though they may not have a term equivalent to AIDN. Here are some examples: + +1. **France** INSEE Code: France uses the INSEE code to uniquely identify communes (municipalities) and administrative regions. For example, Paris has the INSEE code 75056. +2. **United Kingdom** +General Register Office (GRO) Codes: The GRO uses codes to represent the districts responsible for civil registrations. These codes are found on birth, marriage, and death certificates. +3. **Netherlands** +Municipal Code: Dutch municipalities are identified by unique codes in government databases. +4. **United States** +FIPS Codes: The Federal Information Processing Standards (FIPS) codes are used to identify counties and cities in federal and state databases. + +::: + +- **`TYPE`**: Defined as `` in GEDCOM_L as: := {Size=1:35} Type of official or public identifier. + +::: +Example of the Municipality ID of Munchen. +```gedcom +1 _AIDN 09162000 (Munich, Munchen) + 2 TYPE MUNICIPAL-ID +``` +**09162000**: In this case, **0916** is the code for Upper Bavaria, and **2000** specifically refers to Munich. +These identifiers help genealogists and record-keepers reference specific geographic or administrative locations where an event took place, like a birth, marriage, or death registration. +::: -The `<>` 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 state's. -Multiple `<>`s are permitted to support places within multiple hierarchies (for example, a church that's both within an ecclesiastical region and a political region). +- The **`<>`** inside a **`PERIOD_STRUCTURE`** points to larger jurisdictions that this place is a part of, in the timeframe that was valid when the event happened. +Its a pointer to the **Parent jurisdiction**. +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 state's. +Multiple **`<>`** s are permitted to support places within multiple hierarchies (for example, a church that's both within an ecclesiastical region and a political region). Shared place records offer more flexibility than place structures do. A `PLAC` can be replaced by an `SPLAC` without loss of information by making one `SPLAC` record for each non-empty string in the `PLAC`'s payload and linking them together using the `SPLAC`'s `SHARED_PLACE_STRUCTURE`s. @@ -480,6 +647,105 @@ and new records Conversion in the other direction is also possible (from `SPLAC` to `PLAC`) but will in general discard information about individual places in the `SPLAC` chain. +#### `PLACENAME_STRUCTURE` := + +**As there is no more `PLACE_STRUCTURE` with `FORM` as in GEDCOM7, we might need to define `` in chapter 2, same as **"PersonalName"** is defined in GEDCOM7 now.** Because `` can have other elements than `PERSONALName.` + +```gedstruct +n NAME {1:1} g7:INDI-NAME + +1 TRAN {0:M} g7:NAME-TRAN + +2 LANG {1:1} g7:LANG + +1 <> {0:M} + +1 <> {0:M} +``` + +- **NAME** The name(s) of the SPLAC in this `PERIOD`. + +- **TRAN** The Tran structure used to translate the name in this `PERIOD`. + +:::Example +The following example shows the Dutch Province **"Friesland"**, as it is called in 2 different ways: +- It is officially called **"Friesland"** as default name, in Dutch (nl). +- After a certain date it is **officially** called **"Friesland"** AND **"Fryslân"**, with 2 translations, but Frisian people will also call it **"It Heitelân"**, with 2 translations. + +The default name: +```gedcom + 1 NAME Friesland + 2 LANG nl +``` + +In another time period: +``` + 1 NAME Friesland + 2 LANG nl + 1 TRAN Fryslân + 2 LANG fy + 1 NAME It Heitelân (The Homeland) + 2 LANG fy + 1 TRAN Het Vaderland + 2 LANG nl +``` +::: + +As the `PLACENAME_STRUCTURE` will often have names that might have been valid in older times, the structure also has a `NOTE_STRUCTURE` and a `SOURCE_STRUCTURE` to make it possible to add extra information about the names. + +#### PLACE_LOCATION_STRUCTURE := +This structure is meant to contain all means of locating a certain `SPLAC` +```gedstruct +n MAP {0:1} g7:MAP + +1 LATI {1:1} g7:LATI + +1 LONG {1:1} g7:LONG + +1 RADIUS {0:1} g71:RADIUS +n <> {0:1} +n EXID {0:M} g7:EXID + +1 TYPE {0:1} g7:EXID-TYPE +n GOVIDN {0:1} +n MAID {0:1} +n ZIPCD {0:1} + +1 DATE {0:1} + +1 <> {0:M} +n <> {0:M} +n <> {0:M} +``` +:::deprecation Having an `EXID` without an `EXID.TYPE` substructure is deprecated. The meaning of an `EXID` depends on its `EXID.TYPE`. The cardinality of `EXID.TYPE` will be changed to `{1:1}` in version 8.0. ::: + +Location information about a place. + +- **`RADIUS`** is added to have the possibility of defining an area, not just a location, in case the exact location is not known. It can be presented in Kilometers or in Meters. `RADIUS`, as presented here inside the `MAP`, is not supposed to be very large, as that does not give an accurate location. + +::: +Examples: + +```gedcom + +1 MAP + +2 LATI xxx + +2 LONG xxx + +2 RADIUS 2 KM + + ..... + +1 MAP + +2 LATI xxx + +2 LONG xxx + +2 RADIUS 1.75 KM + + ..... + +1 MAP + +2 LATI xxx + +2 LONG xxx + +2 RADIUS 400 M +``` +::: + +- **`<>`** This needs more discussion. In fact the GEDCOM-L's address structure might be a good start, but in here it is just mentioned as a possibility, as it is not clear yet how the address should look. + +- **`GOVIDN`** Defined as **``** in GEDCOM_L as: := {Size=1:14} The official GOV1 Id. ID of the object in the Historical Place Register / Historic Gazetteer (GOV), see http://wiki-de.genealogy.net/GOV. The GOV-ID, for example, has the form **CREGENJO52HG** for **"Cremlingen"**. A list of the GOV-ID is available via the MiniGOV files (download via http://wiki-de.genealogy.net/GOV/Mini-GOV ) or online via the web service of the GOV system http://wiki-de.genealogy.net/GOV/Webservice . + +- **`MAID`** Defined as **``** in GEDCOM_L as: := {Size=1:8} The maidenhead code. (For Maidenhead code see: (https://www.egloff.eu/qralocator/) +The Maidenhead Locator System (a.k.a. QTH Locator and IARU Locator) is a geocode system used by amateur radio operators to succinctly describe their geographic coordinates, which replaced the deprecated QRA locator. + +- **`ZIPCD`** Defined as **``** in GEDCOM_L as: := {Size=1:10} The official ZIP code, called **`ADDRESS_POSTAL_CODE`** in GEDCOM7. +It is changed into **{0:1}** in this specification. + #### `SOURCE_RECORD` := ```gedstruct @@ -1286,6 +1552,10 @@ n SPLAC @@ {1:1} g71:SPLAC An assertion that something took place in or is part of some place. +it is a pointer (link) to a **`SHARED_PLACE_RECORD`**, this pointer is placed in a `SOURCE_RECORD`, an `LDS_ORDINANCE_DETAIL` or in an `EVENT_DETAIL`, to assign a Place for, or to, an event. + +- **`TYPE`** The Hierarchical relationship to the parent **`SPLAC`**. Defined in GEDCOM-L as: := [POLI|RELI|GEOG|CULT] Used to differentiate political (administrative), religious, geographical or cultural associations. For the superior location object the details of its type are defined by the in its record. + The `NOTE_STRUCTURE`s here are about the connection between the topic of the superstructure and the pointed-to place. Notes about the place itself should be placed inside the pointed-to `SHARED_PLACE_RECORD`. @@ -1294,18 +1564,30 @@ A `voidPtr` and `PHRASE` can be used to describe places not referenced by any `S :::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. -```gedcom -0 @I1@ INDI -1 BIRT -2 SPLAC @VOID@ -3 PHRASE at home -``` - -```gedcom +```gedcom 0 @I1@ INDI -1 BIRT -2 PLAC at home + 1 BIRT + 2 SPLAC @SP321@ + 3 PHRASE at home + 3 NOTE This link points to a general "At Home" structure. + +0 @SP321@ SPLAC at home + 1 LANG en + 1 TYPE LOCATION, , 17, Building + 1 PERIOD + 2 TYPE SOURCE + 1 NOTE some more explanation here about "at home" itself. + 1 CREA + 2 DATE 22 JUL 2022 + 3 TIME 20:56:25 + 1 CHAN + 2 DATE 24 SEP 2024 + 3 TIME 15:25:18 ``` +The **`TYPE`** of this **`SPLAC`** is **`LOCATION`**, the general **`SPLAC`** type that is further specified with the **`GOVTYP`** location type 17, from the GOV list, which denotes a building of unknown further description. For the "empty comma", see the explanation of `TYPE`at the `SHARED_PLACE` RECORD. +The **`PERIOD`** has no payload, denoting it is usable from old days till present. For that reason there is also no **`DATE`**. +There is no Location mentioned either, as there is no further description of "at home" given. +This **`SPLAC`** does not point to a parent **`SPLAC`**, but a user could make it point to **`EARTH`** if he wishes. ::: See `SHARED_PLACE_RECORD` for how to convert between `PLAC` and `SPLAC`. diff --git a/specification/gedcom-3-structures-3-meaning.md b/specification/gedcom-3-structures-3-meaning.md index d04bb2f5..7861d373 100644 --- a/specification/gedcom-3-structures-3-meaning.md +++ b/specification/gedcom-3-structures-3-meaning.md @@ -1387,6 +1387,11 @@ A verbatim copy of any description contained within the source. This indicates notes or text that are actually contained in the source document, not the submitter's opinion about the source. This should be, from the evidence point of view, "what the original record keeper said" as opposed to the researcher's interpretation. +#### `TEXT` (Text in SPLAC TYPE's) `g71:SPLAC-TEXT` + +Explaining text that can be added to **`g71:SPLAC-TYPE`**, to further define the **`TYPE`** of an **`SPLAC`** or an **`SPLAC.PERIOD`**. There should not be a comma inside the text as this is used as separator for the sequence. +See at **`g71:SPLAC-TYPE`** for an explanation of what is possible. + #### `TIME` (Time) `g7:TIME` A `Time` value in a 24-hour clock format. @@ -1630,14 +1635,42 @@ A jurisdictional title, describing what type of jurisdiction the superstructure Because of the wide variety of jurisdictional titles in use, this is a free-text value and generally presented in the same language as the place's name. +However, as there are already programs who use a fixed set of jurisdictions, (as for instance FamilySearch online itself does), where those jurisdictions often come from the **`HEAD.PLAC.FORM`**, or **`PLAC.FORM`**, an enumeration set is added to help with the conversion. See **`g71:enumset-SPLAC-TYPE`**. + +It is encouraged that implementations use the **`g71:enumset-SPLAC-TYPE`**, when adding new information and converting older files. As in a future version free-text might no longer be allowed. + +See also **`g7:PLAC-FORM`** which is the list version of **`g71:SPLAC-TYPE`**. + :::example -The following represents that Baltimore is a city. +The following represents a freeform version for the City of Baltimore: +``` +0 @SP2@ SPLAC Baltimore +1 TYPE City, POLI +``` -```gedcom +Next, the same, but this time with the enumset: +``` 0 @SP2@ SPLAC Baltimore -1 TYPE City +1 TYPE CITY, POLI +``` +Only difference here is that the enum value itself is in uppercase, as in the enumset. +::: + +To help with readability, this **`TYPE`** has the following extra feature: +- The TYPE-line is combinable with a possible other **`TYPE`** (with an enumset or with text) coming from the GEDCOM-line directly following or preceding the current one. +- The line with text, must be of type **`g71:SPLAC-TEXT`** and can never be a preceding line, it is always the last line in a sequence. There must not be a comma in this free text, as this is the separator in the sequence. + +:::example + +The following represents an "old" name for the Netherlands **"De Lage Landen"**, in the time it was a kingdom and part of the Holy Roman Empire: + +```gedcom +0 @SP11@ SPLAC De lage Landen + 1 LANG nl + 1 TYPE COUNTRY, POLI, 31, Part of the "Holy Roman Empire". ``` -::: +The Value 31 is the GOV number for a kingdom. POLI is the type of hierarchical realtionship. After the last comma is the free text. +::: See also `g7:PLAC-FORM` which is the list version of `g71:SPLAC-TYPE`. diff --git a/specification/gedcom-3-structures-4-enumerations.md b/specification/gedcom-3-structures-4-enumerations.md index bf70b9a4..ecfaf315 100644 --- a/specification/gedcom-3-structures-4-enumerations.md +++ b/specification/gedcom-3-structures-4-enumerations.md @@ -241,3 +241,83 @@ and applications should be prepared to encounter non-current values. | `MARRIED` | Married name, assumed as part of marriage. | | `PROFESSIONAL` | Name used professionally (pen, screen, stage name). | | `OTHER` | A value not listed here; should have a `PHRASE` substructure | + +### `g71:enumset-SPLAC-TYPE` + +The numbers in the Meaning column, denote the `GOVID` number from GEDCOM_L as in http://gov.genealogy.net/type/list +| Value | Meaning | +|---|---| +|EARTH | The global level that includes all continents, countries, and regions. It represents the entirety of human civilization and geographical space as the outermost jurisdictional layer. | +|SEA | A body of saline water more directly associated with a specific landmass or group of landmasses than the vast open oceans.| +|COUNTRY | (34) A nation with its own government, occupying a particular territory. (e.g., United States, Denmark)| +|STATE | (7) A division within a country, typically large and governed by regional laws. For example, in the U.S., it's the **"state"** (e.g., California), while in Canada, it's the **"province"** (e.g., Ontario).| +|COUNTY | (222) A smaller division within a state or province, often handling local administration. For example, "Los Angeles County" in California.| +|PROVINCE | (45) A division within a country, typically large and governed by regional laws, as in the Netherlands (Also see `STATE`)| +|DISTRICT | (5) A geographical area or administrative region within a county. It often serves to organize larger municipalities or rural areas, especially in places where counties are divided into multiple administrative sections. | +|CODEINSEE | In France, this is the national identification code used for administrative purposes, specifically for geographical divisions such as regions, departments, or cities.| +|CITY | (51) A municipality or large urban area within a county or district, where people live and work. Examples include "Paris" or "New York City." (A city can consist of suburbs, that in turn could have been small villages once)| +|VILLAGE | (54) A smaller settlement than a city, often in rural areas. Examples include "Vejleby" in Denmark. (Small villages maybe later become a suburb of a City).| +|ZIPCODE | A postal code used to identify specific areas for mail delivery, which can also help locate an event. In the U.S., this is typically a five-digit code, e.g., 90210. In the Netherlands a Zipcode, is a small area in a city or a small city itself)| +|LOCATION | Smallest possible "area", indicating an exact place within a city or village, such as a street address, building, or landmark. Can also be a house, a cemetary, a hospital, a Farm etc. Or a place at sea we know not much about.| + +Almost all Values are in fact Area's, that go from largest: `EARTH`: (at the top) to smallest: `LOCATION`: (at the bottom). This list might not be complete yet, but its a start. +The smallest one is called `LOCATION`. As thats also a bit of a reference to `_LOC` of GEDCOM-L. (In fact `LOCATION` is not really an "area".) +Also `EARTH` is added at the top, so we can give for instance a place at sea, that has no superior than the earth itself, the possibility to also have a superior. + +Now GEDCOM-L has around 280 Location `TYPE's`, but a lot of them are in fact of the lowest level, in the above list they are of Type `LOCATION`. (Farm, Cemetary etc) +So there is an extra SubType-TAG just for `LOCATION`, to further specify the `TYPE` of the `LOCATION`. But as that is a long list the already existing `GOVID` list is used for that, and its not specified here. See `GOVTYP` in the `PERIOD-STRUCTURE` for that. + +**For instance:** + +**1 TYPE LOCATION, GEOG, 4, Farm** +or + **1 TYPE LOCATION, RELI, 89, Cemetary** +Both with their `GOVID` GEDCOM_L number, separated by a comma, after the `SPLAC-TYPE`: `LOCATION` and the Demographical Type. Those numbers point to the GOV list of types. + +If the `GOVID` number is not know, specification could be: +**1 TYPE LOCATION, GEOG, , Farm** +So with an empty comma's just as in the original Jurisdiction list of GEDCOM 7. + +With this enumset and that GOVLIST we can convert existing GEDCOM's. +::: +Maybe the GOV list should have some kind of **"GENERAL"** or **"UNKNOWN"** type, maybe take the value 0 for that. So in case a GEDCOM has no real definition we could write: + +**1 TYPE LOCATION, POLI, 0, Unknown** + +@Albertemmerich: Could this list https://gov.genealogy.net/type/list be translated into English, or an English column added? That would make it way easier to use. +::: + +*** +### `g71:enumset-DATA-INFO-TYPE` + +| Value | Meaning | +|---|---| +| SOURCE | The information found here, is as seen from the researcher perspective. So as it is found in information records. No user processing has taken place. | +| USER | The information found here, is as seen from a conclusion perspective, so after a user has processed the information from certain records, and added his/hers own conclusions.| +| OWN | The information found here did not directly come from any records, but it is the users own work (for instance if someone has a lot of own info about Farms) + +`DATA-INFO-TYPE` is used to specify the Source of the data in a `PERIOD_STRUCTURE`. But it is defined in such a way that it could also be used for other things later, hence this name for the enumset. + +*** +### `g71:enumset-DEMOGRAPHICAL-DATA` + +| Value | Meaning | +|---|---| +| POPULATION | The Demographical data that was collected, was related to the Population of a certain area. | +| HOUSEHOLD | The Demographical data that was collected, was related to the number of Households in a certain area. | +| RESIDENT | The Demographical data that was collected, was related to the number of residents of a certain area. | + +The `` is used to specify the type of data that is gathered for a Census and other collections. It is used in the **`PERIOD'S`** of an `SPLAC record. + +*** + +### `g71:enumset-HIERARCHICAL-TYPE` + +| Value | Meaning | +|---|---| +| POLI | Political relationship | +| RELI | Religious relationship | +| GEOG | Gegraphical relationship | +| CULT | Cultural relationship | + +The `` is used to specify the type of the relation between an `SPLAC` and its parent, used in the link of the `SHARED_PLACE_STRUCTURE`. And in the `SPLAC`itself to denote the type of the total `SPLAC` record.. diff --git a/specification/gedcom-6-appendix-examples.md b/specification/gedcom-6-appendix-examples.md new file mode 100644 index 00000000..cf8e945e --- /dev/null +++ b/specification/gedcom-6-appendix-examples.md @@ -0,0 +1,636 @@ +# Appendix B: GEDCOM Examples + + +## General remarks: + +These examples differ a bit from **"Real GEDCOM"**. +Thats because of the following: + +- For easier reading the lines are indented. Now it is "visible" where the "blocks" inside a GEDCOM structure start and end. +- Also, comment is added behind some of the GEDCOM lines, so its easier to see where a certain line is based on (what GEDCOM7 and/or GEDCOM-L tags) +- Some lines look like "....." that means they are left out for that example. But should be filled, in a real GEDCOM. +- A line that says "CREA and CHAN" should be the real values instead. + +#### $\color{red}{The\ above\ should\ ofcourse\ be\ done\ right\ in\ a\ real\ GEDCOM\ file!}$ +**It only serves as explanation and better visibility here.** + +Many examples have some explaining text added, about the "What" and "Why" of certain parts of it. + +*** + +## Examples for SPLAC: +Here some examples for `SPLAC` are worked out, as complete as possible. Because with that we can see the possibilities of the extended `SPLAC`Record. + +`SPLAC`, as it is already designed at this moment, is a newer and way better version of the original `PLAC` data as it is defined now. + +This add's some changes to that design, and made it a bit of a combination with the `_LOC` from the GEDCOM-L specs. The comments after the TAG's often point to that. + +#### $\color{red}{SPLAC\ example 1:}$ + +Here a cemetery and a (fantasy) addres in Sneek are used, which is a city in the province of Friesland in the Netherlands. The cemetery had 2 locations (and names) depending on a date. +Sneek had a different name, before and after 1230. +The province Friesland had more names and belonged in a different hierarchy depending on a date period. +Same for the Country The Netherlands itself. +So a lot of different problems are in this one example. + +Here the cemetery probably should have been in a religious hierarchy, but to keep it simple it is said to be in a political hierarchy. + +### SPLAC of the RK Cemetery in Sneek (Valid from 1892) +From 1892, there was an RK Cemetery in Sneek (described in the first `PERIOD`), but before the year 1892 the General Cemetery was used also for Catholics (this cemetery is described in the second `PERIOD`) + +**Just as an example**, this `SPLAC` uses 5 systems of determining the position: `MAP, ADDR, POST, GOV` and `MAID`. +Also, the 2 `PERIOD`s in this `SPLAC`, **both point to the same City: Sneek**. + +#### This SPLAC has a LOCATION TYPE with 4 parameters: +**1 TYPE LOCATION, POLI, 89, Cemetery** +- The type: `LOCATION` itself +- Followed by the type of the administrative hierarchy, here POLI (political) +- Followed bij the `GOV` number type of a cemetery +- Followed by an optional descriptive text +- Each separated by a comma. + +Refer to the specification itself, for a definition of this `TYPE`. +(Compare them in the examples, to the `SPLAC`-Types of the other `SPLAC`s.) + +```gedcom +0 @SP53@ SPLAC RK Begraafplaats Sneek Roman catholic cemetery + 1 LANG nl + 1 TYPE LOCATION, POLI, 89, Cemetery (89=cemetery, POLI=Political hierarchy) + 1 PERIOD FROM 1892 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE FROM 1892 (existed since 1892) + 2 TRAN RK Begraafplaats Sneek + 3 LANG nl + 2 MAP + 3 LATI N53.040175 + 3 LONG E5.669792 + 2 ADDR Leeuwarderweg 83 + 3 CONT 8603 CM Sneek + 3 CONT Nederland + 2 POST 8603CM () + 2 GOV RKBEEKJO23UA + 2 MAID JO23ua (Maidenhead code: https://www.egloff.eu/qralocator/) + 2 SPLAC @SP1@ ((_LOC in GEDCOM_L) SPLAC: City Sneek) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1230 (City Sneek existed AFTER 1230) + 1 PERIOD From 1827 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1827 (existed since 1827) + 2 TRAN Algemene Begraafplaats Sneek (Other cemetery, used before 1892 + 3 LANG nl + 2 MAP Slightly diff. position then the other cemetery in the first PERIOD + 3 LATI N53.039586 + 3 LONG E5.661156 + 2 ADDR Kerkhoflaan 31a + 3 CONT 8602 TX Sneek + 3 CONT Nederland + 2 POST 8602TX () + 2 GOV ALGEEKJO23TA + 2 MAID JO23ta (Maidenhead code: https://www.egloff.eu/qralocator/) + 2 SPLAC @SP1@ ((_LOC in GEDCOM_L) link to SPLAC: City Sneek) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1230 (City Sneek existed AFTER 1230) + 1 CREA + 2 DATE 22 JUL 2022 + 3 TIME 20:56:25 + 1 CHAN + 2 DATE 29 SEP 2024 + 3 TIME 15:25:18 +``` +*** +### SPLAC of a Home address in Sneek. +#### The address links to the City of Sneek itself. +```gedcom +0 @SP8@ SPLAC Marktstraat 123 Sneek 9Home at non-existing nr in the Marktstraat in Sneek0 + 1 LANG nl + 1 TYPE LOCATION, POLI, 236, House (House includes GOV-Type) + 1 PERIOD FROM 1400 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 1400 (Fantasy: The Marktstraat existed since 1400) + 2 TRAN Marktstraat 125 Sneek + 3 LANG nl + 2 MAP + 3 LATI 53.03243992883088 + 3 LONG 5.6588164028087515 + 2 ADDR Marktstraat 125 (Constructed according to GEDCOM-L) + 3 CONT 8601 CR Sneek + 3 CONT Nederland + 2 POST 8601CR () + 2 SOUR ....... + 2 NOTE ....... + 2 SPLAC @SP1@ ((_LOC in GEDCOM_L) link to SPLAC: City Sneek) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1230 (City Sneek existed AFTER 1230) + 1 CREA + 2 DATE 22 JUL 2022 + 3 TIME 20:56:25 + 1 CHAN + 2 DATE 21 SEP 2024 + 3 TIME 15:25:18 +``` +*** +### SPLAC of todays City of Sneek. +#### Sneek links to the province of Friesland today AND in the old days +So there are 2 links inside, 1 in each `PERIOD` structure. Both go to the same City Sneek. +```gedcom +0 @SP1@ SPLAC Sneek This is the "Main Name", shown in tree's and records + 1 LANG nl + 1 TYPE CITY, POLI, 51 (regional authority, includes GOV-Type) + 1 PERIOD From 1230 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1230 + 2 TRAN SNEEK + 3 LANG nl + 2 TRAN Snits + 3 LANG fy + 2 MAP + 3 LATI N12.3 + 3 LONG W45.6 + 3 RADIUS 3km + 3 EXID ......... + 3 NOTE ........ + 2 GOV GEMEEKJO23TA (https://gov.genealogy.net/item/show/GEMEEKJO23TA) + 2 GOV object_1305874 (https://gov.genealogy.net/item/show/object_1305874) + 2 SOUR @S77@ + 3 QUAY 2 + 2 OBJE + 3 TITL The City: Sneek + 3 FILE https://nl.wikipedia.org/wiki/Sneek_(stad) + 4 FORM HTML + 3 NOTE + 2 SPLAC @SP2@ (_LOC in GEDCOM_L) link to SPLAC: province Friesland as it is today) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1 JAN 1880 TO 31 DEC 1899 + 2 PHRASE Some text here + 2 NOTE Texts about the Shared place structure. (can be many notes) + 1 PERIOD FROM 1000 TO 1230 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE FROM 1000 TO 1230 + 2 TRAN Ter Snake + 3 LANG nl + 3 NOTE Notes about the "province" in those days. + 3 SOUR @S1@ + 4 multimedia link + 4 NOTE's for the Source + 2 SPLAC @S2@ (links to SPLAC:Friesland, "KINGDOM" PERIOD) + 3 TYPE CULT (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1 JAN 1000 TO 31 DEC 1500 + 2 PHRASE Some text here + 2 NOTE about the Shared place structure. (can be many notes) + 1 CREA + 2 DATE 22 JUL 2022 + 3 TIME 20:56:25 + 1 CHAN + 2 DATE 26 SEP 2024 + 3 TIME 15:25:18 +``` +*** +### SPLAC of the province of Friesland. + +#### First PERIOD, the default period. +This default period, is valid since 1450. It links to the general `SPLAC` from the Netherlands. +#### Second PERIOD in here, is only about NAME change, so it has no further link. +This period links to the same "higher" Jurisdiction as the first `PERIOD` in this `SPLAC`, as it does not have a link of its own. (But if someone wished a link can be added) + +But we could also define that each `PERIOD` ALWAYS must have a link, to make it easier for programs to deal with them. +#### Third PERIOD, is type USER +Contents here is partly fantasy. +Because the third `PERIOD` is of type `USER`, there is a link to a `SUBM` record added, to be able to define the SUBMitter responsible for the "conclusion" of the information. +```gedcom +0 @SP2@ SPLAC Friesland + 1 LANG nl + 1 ABBR FR (abbreviation of the NAME, optional) + 2 TYPE ISO 3166 (official abbreviation type of the Province Name Friesland) + 1 TYPE PROVINCE, POLI, 45 (division smaller then country) + 1 PERIOD FROM 1450 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE FROM 1450 + 2 GOVID FRIANDJO23VE () + 3 SOUR @S9@ + 4 QUAY 2 + 3 OBJE + 4 TITL Province of Friesland + 4 FILE https://gov.genealogy.net/item/show/FRIANDJO23VE + 5 FORM HTML + 4 NOTE + 2 SPLAC @SP10@ (link to the SPLAC: NETHERLANDS) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1 JAN 1880 + 2 PHRASE Some text here + 2 NOTE Texts about the Shared place structure. (can be many notes) + 1 PERIOD FROM 1 JAN 1997 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE FROM 1 JAN 1997 + 2 NAME Friesland + 3 LANG nl + 2 TRAN Fryslân + 3 LANG fy + 2 NAME It Heitelân + 3 LANG fy + 2 TRAN Het Vaderland + 3 LANG nl + 1 PERIOD FROM 1000 TO 1450 + 2 TYPE USER (USER= conclusion perspective) + 2 DATE FROM 1000 TO 1450 + 2 NAME Ter Snake (Name of the province in this timeframe) + 3 LANG nl + - - - + - - - + 2 SPLAC @SP11@ (link SPLAC: De Lage Landen (Later: The Netherlands)) + 3 TYPE RELI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE DATE 0 TO 1648 + 2 PHRASE Some text here + 2 NOTE Texts about the Shared place structure. (can be many notes) + 2 SUBM @B001@ (SUBMitter responsable for the "conclusion" of the information) +CREA and CHAN +``` +*** +### SPLAC of the NETHERLANDS after 1648 +#### This is the first description of the Netherlands, as "Country" from 1648 till today. + +```gedcom +0 @SP10@ SPLAC NEDERLAND + 1 LANG nl + 1 TYPE COUNTRY, POLI, 7 (Federal State) + 1 PERIOD FROM 1648 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE FROM 1648 + 2 GOV object_1280959 ( of the Netherlands) + 3 SOUR @S99@ + 4 QUAY 2 + 3 OBJE + 4 TITL Kingdom of the Netherlands + 4 FILE https://gov.genealogy.net/item/show/object_1280959 + 5 FORM HTML + 4 NOTE + 2 SPLAC @SP2000@ (link to the SPLAC: EARTH) + 3 TYPE GEOG (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 2 PHRASE Some text here + 2 NOTE Texts about the Netherlands. (can be many notes) +CREA and CHAN +``` +*** +### SPLAC of the Netherlands before 1648 +#### Second description of the Netherlands before 1648, as part of the Roman Empire. +(Partly fantasy) +```gedcom +0 @SP11@ SPLAC De lage Landen + 1 LANG nl + 1 TYPE COUNTRY, POLI, 31 (Kingdom, Part of the Holy Roman Empire) + 1 PERIOD FROM 0 TO 1648 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 0 TO 1648 + 2 SPLAC @SP2000@ (link to the SPLAC: EARTH) + 3 TYPE GEOG (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 2 PHRASE Some text here + 2 NOTE Texts about the Netherlands in those days +CREA and CHAN +``` +*** +### SPLAC of the Earth (highest Jurisdiction) +#### The EARTH jurisdiction, fantasy. Just to have a complete jurisdiction system from high to low. +```gedcom +0 @SP2000@ SPLAC EARTH + 1 LANG en + 1 TYPE EARTH + 1 PERIOD + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE FROM UNKNOWN +CREA and CHAN +``` + +*** + +#### $\color{red}{SPLAC\ example\ 2:}$ + +### SPLAC of the city of Amsterdam and some of its suburbs + +The "parent" of a City (or other jurisdiction) changed over the years: + +Amsterdam was first mentioned in a doc around 1275 as "Amstelledamme" (a dam in the "river" Amstel). But it was a way smaller city. Over the years it grew and "has eaten" some of the smaller little villages around it. (Sloten, Buiksloot, Nieuwendam, Nieuwer Amstel) +But those smaller villages, once were independant too, and pointed to the province of Noord-Holland. Until one day they became part of Amsterdam, so from that day their "parent" was no longer a province, but another city: Amsterdam, which in turn pointed to the province Noord-Holland. + +In `SPLAC's` that looks like this: + +```gedcom +0 @SP5@ SPLAC Sloten + 1 LANG nl + 1 TYPE CITY, POLI, 51 (regional authority, includes GOV-Type) + 1 PERIOD From 800 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 800 + ..... (MAP structure or other location definition) + ..... + 2 SPLAC @SP2@ (link to SPLAC: province Noord-Holland) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 800 + 1 PERIOD FROM 1921 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1921 + ..... (MAP structure ot other location definition) + ..... + 2 SPLAC @SP1@ (link to SPLAC: City Amsterdam) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1921 +CREA and CHAN + +0 @SP6@ SPLAC Buiksloot + 1 LANG nl + 1 TYPE CITY, POLI, 51 (regional authority, includes GOV-Type) + 1 PERIOD From 1100 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1100 + ..... (MAP structure or other location definition) + ..... + 2 SPLAC @SP2@ (link to SPLAC: province Noord-Holland) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1100 + 1 PERIOD FROM 1921 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1921 + ..... (MAP structure ot other location definition) + ..... + 2 SPLAC @SP1@ (link to SPLAC: City Amsterdam) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1921 +CREA and CHAN + +0 @SP7@ SPLAC Nieuwer Amstel + 1 LANG nl + 1 TYPE CITY, POLI, 51 (regional authority, includes GOV-Type) + 1 PERIOD From 1200 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1200 + ..... (MAP structure or other location definition) + ..... + 2 SPLAC @SP2@ (link to SPLAC: province Noord-Holland) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1200 + 1 PERIOD FROM 1896 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1896 + ..... (MAP structure ot other location definition) + ..... + 2 SPLAC @SP1@ (link to SPLAC: City Amsterdam) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1896 +CREA and CHAN + +0 @SP1@ SPLAC Amsterdam + 1 LANG nl + 1 TYPE CITY, POLI, 51 (regional authority, includes GOV-Type) + 1 PERIOD From 1275 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE From 1275 (First mentioned in a doc as "Amstelledamme") + ..... (MAP structure ot other location definition) + ..... + 2 SPLAC @SP2@ (link to SPLAC: province Noord-Holland) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1 JAN 1880 TO 31 DEC 1899 +CREA and CHAN + +0 @SP2@ SPLAC Noord-Holland + 1 LANG nl + 1 TYPE PROVINCE, POLI, 45 (division smaller then country) + 1 PERIOD FROM 1000 + 2 TYPE SOURCE (SOURCE=researcher perspective) + 2 DATE FROM 1000 + ..... + ..... + 2 SPLAC @SP10@ (link to the SPLAC: NETHERLANDS) + 3 TYPE POLI (HIERARCHICAL_RELATIONSHIP,POLI,RELI,GEOG,CULT) + 3 DATE FROM 1200 (fantasy) +CREA and CHAN +``` + +*** + +#### $\color{red}{SPLAC\ example\ 3:}$ + +### SPLAC of the city of Subotica in Serbia, that "moved" from 1 parent to another. + +The "Parent SPLAC" of a Place, might have changed over the years. (town that was in the Austo-Hungarian empire, and at another time Hungary, and at another time Serbia) + +As an example we look at Subotica in Serbia for that. Now the following scheme is not complete and might contain errors, but for our example thats not so important. + +Schematically it is: + +| **DATE** | **Place name** | **Parent SPLAC (State/Political Entity)** | **Description** | **Relationship** | +|-------------------|------------------------------|----------------------------------------------------------|----------------------------------------------------------------------|--------------------------------------------------| +| **Before 1526** | Zabotka / Zabatka | Kingdom of Hungary (1000–1526) | Pre-Ottoman rule during the independent medieval Kingdom of Hungary | POLI | +| **1526** | Zabadka / Zabatka | Ottoman Empire | City nearly destroyed during the Ottoman conquest | POLI / RELI (due to Ottoman religious influence) | +| **1686** | Zabatka / Szabadka | Habsburg Monarchy (Royal Hungary, 1526–1867) | Ottoman rule ended, became part of the Habsburg Monarchy | POLI / RELI (Catholic influence of the Habsburgs) | +| **1779** | Maria-Theresiapolis | Habsburg Monarchy (Hungarian Empire, part of Habsburg-controlled Hungary) | Named after Maria Theresia and given royal city status | CULT (cultural influence due to royal recognition)| +| **1849** | Subotica / Szabadka | Voivodeship of Serbia and Banat of Temeschwar | After Hungarian Revolution of 1848, became part of this entity | POLI / GEOG (geographically redefined) | +| **1876** | Subotica / Szabadka | Austro-Hungarian Empire (Kingdom of Hungary, 1867–1918) | Integrated back into the Hungarian Kingdom under the Austro-Hungarian Empire | POLI | +| **1918** | Szabadka (Subotica) | Kingdom of Serbs, Croats, and Slovenes (unofficially) | Post-World War I change | POLI | +| **June 4, 1920** | Subotica / Szabadka | Kingdom of Serbs, Croats, and Slovenes | Officially part of the Kingdom after the Treaty of Trianon | POLI | +| **October 3, 1929**| Subotica / Szabadka | Yugoslavia | Kingdom of Yugoslavia formed under King Alexander I | POLI | +| **1941** | Subotica (Szabadka in Hungarian)| Hungary | Annexed by Hungary during World War II | POLI / CULT (Hungarian cultural influence) | +| **1945** | Subotica (Szabadka in Hungarian)| Socialist Federal Republic of Yugoslavia | Socialist state under Tito | POLI | +| **1946** | Subotica (Szabadka in Hungarian)| Socialist Federal Republic of Yugoslavia | Established as part of post-war Yugoslavia | POLI | +| **April 27, 1992** | Subotica (Szabadka in Hungarian)| Federal Republic of Yugoslavia (Serbia and Montenegro) | After Yugoslavia broke up | POLI | +| **2006** | Subotica (Szabadka in Hungarian)| Independent Serbia | Serbia becomes fully independent | POLI | + +#### As we see here, some realations were in fact a combination, for instance "POLI/RELI", so maybe we should allow this enum tag to have 2 values, separated by a slash **("/")**, as in the following examples. + +There will be a subset of this scheme in the following SPLAC's and not all Parent SPLAC's will contain all information. + + **Its just to get an idea how to solve this problem!** + +## SPLAC City: Subotica (Zabadka / Zabatka) in Serbia +This City has had its Name changed over the years and also the "superior" of the place changed many times. + +```gedcom +0 @SP001@ SPLAC Subotica ( City in Serbia) + 1 LANG en + 1 TYPE CITY, POLI, (regional authority, includes GOV-Identifier) + 1 PERIOD + 2 TYPE SOURCE SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 27 APR 1992 + 2 TRAN Subotica + 3 LANG en + 2 tran Szabadka + 3 LANG hu + 2 MAP + 3 LATI 46.09609651 + 3 LONG 19.680925168 + ..... + ..... + 2 SPLAC @SP002@ ( (_LOC in GEDCOM_L) link to SPLAC: Independant Serbia (today) + 3 TYPE POLI + 3 DATE FROM 27 APR 1992 + ..... + 1 PERIOD + 2 TYPE SOURCE + 2 DATE TO 1526 + 2 TRAN Zabadka + 3 LANG hu + 2 TRAN Zabatka + 3 LANG hu + ..... + 2 SPLAC @SP003@ (link to SPLAC: Kingdom of Hungary (1000-1526) ) + 3 TYPE POLI + 3 DATE TO 1526 + ..... + 1 PERIOD + 2 TYPE SOURCE + 2 DATE FROM 1526 TO 1686 + 2 TRAN Zabotka + 3 LANG hu + 2 TRAN Zabatka + 3 LANG hu + ..... + 2 SPLAC @SP004@ ( (_LOC in GEDCOM_L) link to SPLAC: Ottoman Empire) + 3 TYPE POLI / RELI (Due to Ottoman religious influence) + 3 DATE FROM 1526 TO 1686 + ..... + 1 PERIOD (Ottoman rule ended became part of the Habsburg Monarchy) + 2 TYPE SOURCE + 2 DATE FROM 1686 TO 1779 + 2 TRAN Zabotka Name did not change so it MUST be set otherw. Name is from 1ePeriod + 3 LANG hu + 2 TRAN Zabatka + 3 LANG hu + ..... + 2 SPLAC @SP005@ (link SPLAC: Habsburg Monarchy - Royal Hungary, 1526-1867) + 3 TYPE POLI/ RELI (Due to religious Catholic influence of the Habsburgs) + 3 DATE FROM 1686 TO 1779 + ..... + 1 PERIOD + 2 TYPE SOURCE + 2 DATE FROM 1779 TO 1849 (Hungarian Empire, part of Habsburg controlled Hungary) + 2 TRAN Maria-Theresiapolis (Given by Empress Maria Theresia) + 3 LANG nl + ..... + 2 SPLAC @SP005@ (link SPLAC: Hungarian Empire - Hungarian Empire, part of Habsburg controlled Hungary) + 3 TYPE CULT (Cultural influence due to royal recognition) + 3 DATE FROM 1779 TO 1849 + ..... + 1 PERIOD + 2 TYPE SOURCE + 2 DATE FROM 1849 TO 1876 (parent:Voivodeship of Serbia and Banat of Temeschwar) + 2 TRAN Zabotka + 3 LANG hu + 2 TRAN Zabatka + 3 LANG hu + ..... + 2 SPLAC @SP007@ (Voivodeship of Serbia and Banat of Temeschwar FROM 1849 TO 1918) + 3 TYPE POLI/ GEOG (geographically redefined as part of a larger region) + 3 DATE FROM 1849 TO 1876 + ..... + 1 PERIOD + 2 TYPE SOURCE + 2 DATE FROM 1876 TO 1918 (Austro-Hungarian Empire, Kingdom of Hungary, 1867-1918) + 2 TRAN Zabotka + 3 LANG hu + 2 TRAN Zabatka + 3 LANG hu + ..... + 2 SPLAC @SP006@ (Link to SPLAC: Austro-Hungarian Empire, Kingdom of Hungary, 1867-1918) + 3 TYPE POLI + 3 DATE FROM 1876 TO 1918 (integrated back in Hungarian empire) + ..... + ..... + 1 CREA + 2 DATE 22 JUL 2022 + 3 TIME 20:56:25 + 1 CHAN + 2 DATE 21 SEP 2024 + 3 TIME 15:25:18 +``` + +**Now the "Countries" that Subotica "links" to** + +**In fact there might have been Jurisdictions in between the City and the Country / Kingdom, but we leave that out! !** +In this case the ""Countries" +Subotica links to were very diferent, also in size, thats why here is choosen to have separate `SPLAC's` for each "Country". +Further, the information inside the following SPLAC's is limited, its just an example. + +## SPLAC Country: Independent Serbia (today) FROM 27 APR 1992 + +```gedcom +0 @SP002@ SPLAC Serbia (Independent Serbia) + 1 LANG en + 1 TRAN Szerbia + 2 LANG hu + 1 TYPE COUNTRY, POLI, 7 (Serbia independant Federal State) + 1 PERIOD FROM 27 APR 1992 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 27 APR 1992 + 2 SPLAC @SP100@ link to the SPLAC: EARTH + 3 TYPE GEOG HIERARCHICAL_RELATIONSHIP, can be POLI, RELI, GEOG, or CULT + ..... +CREA and CHAN +``` +## SPLAC Country: Kingdom of Hungary TO 1526 + +```gedcom +0 @SP003@ SPLAC Kingdom of Hungary (Kingdom of Hungary (1000-1526)) + 1 LANG en + 1 TYPE COUNTRY, POLI, 31 (Kingdom) + 1 PERIOD TO 1526 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE TO 1526 + 2 SPLAC @SP100@ link to the SPLAC: EARTH + 3 TYPE GEOG HIERARCHICAL_RELATIONSHIP, can be POLI, RELI, GEOG, or CULT + ..... +CREA and CHAN +``` +## SPLAC Country: Ottoman Empire FROM 1526 TO 1686 + +```gedcom +0 @SP004@ SPLAC Ottoman Empire + 1 LANG en + 1 TYPE COUNTRY, POLI, 31 (Kingdom) + 1 PERIOD FROM 1526 TO 1686 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 1526 TO 1686 + 2 SPLAC @SP100@ link to the SPLAC: EARTH + 3 TYPE GEOG HIERARCHICAL_RELATIONSHIP, can be POLI, RELI, GEOG, or CULT + ..... +CREA and CHAN +``` +## SPLAC Country: Habsburg Monarchy - Royal Hungary FROM 1526 TO 1867 + +```gedcom +0 @SP005@ SPLAC Habsburg Monarchy (Habsburg Monarchy - Royal Hungary, 1526-1867) + 1 LANG en + 1 TYPE COUNTRY, POLI, 31 (Kingdom) + 1 PERIOD FROM 1686 TO 1799 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 1686 TO 1799 + 2 SPLAC @SP100@ link to the SPLAC: EARTH + 3 TYPE GEOG HIERARCHICAL_RELATIONSHIP, can be POLI, RELI, GEOG, or CULT + ..... +CREA and CHAN +``` +## SPLAC Country: Austro-Hungarian Empire (Kingdom of Hungary) FROM 1867 TO 1918 + +```gedcom +0 @SP006@ SPLAC Habsburg Monarchy (Habsburg Monarchy - Royal Hungary, 1526-1867) + 1 LANG en + 1 TYPE COUNTRY, POLI, 31 (Kingdom) + 1 PERIOD FROM 1867 TO 1918 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 1867 TO 1918 + 2 SPLAC @SP100@ link to the SPLAC: EARTH + 3 TYPE GEOG HIERARCHICAL_RELATIONSHIP, can be POLI, RELI, GEOG, or CULT + ..... +CREA and CHAN +``` + +## SPLAC Country: Voivodeship of Serbia and Banat of Temeschwar FROM 1849 TO 1918 +```gedcom +0 @SP007@ SPLAC Voivodeship of Serbia and Banat of Temeschwar + 1 LANG en + 1 TYPE COUNTRY, POLI, 7 (Federal State) + 1 PERIOD FROM 1849 TO 1918 + 2 TYPE SOURCE (SOURCE=researcher perspective, USER= conclusion perspective + 2 DATE FROM 1849 TO 1918 + 2 SPLAC @SP100@ link to the SPLAC: EARTH + 3 TYPE GEOG HIERARCHICAL_RELATIONSHIP, can be POLI, RELI, GEOG, or CULT + ..... +CREA and CHAN +``` +#### There are more but they are left out.