GEDCOM 5.5EL: Unterschied zwischen den Versionen
K (→TYPE Subtag des EVEN Tags: Wiki Syntax) |
K (Schützte „GEDCOM 5.5EL“: Aktualisierung durchgeführt ([edit=sysop] (unbeschränkt) [move=sysop] (unbeschränkt))) |
||
(23 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''( | {{Infobox|'''(Bitte!''' Wenn an diesem Artikel geändert wird, bitte auch die [[:en:Gedcom_5.5EL|englische Version]] entsprechend anpassen! Danke!)'''}} | ||
==Hinweis auf neuere Vereinbarungen== | |||
Nach Abschluss der Arbeiten zu GEDCOM 5.5EL hat der Verein für Computergenealogie mit einer größeren Anzahl von Programmautoren eine erweiterte Arbeitsgruppe zur korrekten Interpretation des GEDCOM Standards 5.5.1 ins Leben gerufen, diese Arbeitsgruppe wurde als [[GEDCOM-L|Gedcom-L]] bezeichnet. Die Gedcom-L hat neben vielen anderen Themen auch alle Punkte der GEDCOM 5.5EL aufgegriffen und an den Stellen auch modifiziert, wo die Lösungen der GEDCOM 5.5EL dem GEDCOM-Standard widersprachen. Der neue Stand der Vereinbarungen ist zu finden unter: | |||
[[:Kategorie:GEDCOM-Tag]] | |||
'''Die im nachfolgenden dargestellten Lösungen werden nur noch aus historischen Gründen gezeigt, sie sollten auf keinen Fall mehr in Genealogie-Programmen verwendet werden.''' | |||
== | =Spezifikation Gedcom 5.5EL= | ||
Die | |||
* Hersteller der Genealogieprogramme | |||
**[[Ages!]], | |||
**[[DYNAS-TREE]], | |||
**[[GES-2000]], | |||
**[[GF-Ahnen]], | |||
**[[PC-Ahnen]], | |||
**[[GEDCOM 2 Map]] | |||
* und der [[Verein für Computergenealogie e.V.]] | |||
schlagen gemeinsam folgende Erweiterung des [[GEDCOM]] 5.5 Standards vor: | |||
==High-Level-Entitiy "Location"== | |||
< | Die High Level Entity "Location" wird eingeführt mit folgender Struktur: | ||
< | <source lang="gedcom">0 @P65@ _LOC | ||
< | 1 NAME <PLACE_NAME> 1:M | ||
2 DATE <DATE_VALUE> 0:1 | |||
2 SOUR <SOURCE_CITATION> | |||
< | 2 NAMC <PLACE_NAME_ADDITION> 0:1 | ||
</ | 2 _LANG <LANGUAGE> 0:1 | ||
1 _FPOST <FOKO_POSTCODE> 0:M | |||
2 DATE <DATE_VALUE> 0:1 | |||
1 POST <POSTCODE> 0:M | |||
2 DATE <DATE_VALUE> 0:1 | |||
2 SOUR <SOURCE_CITATION> 0:M | |||
1 _FSTAE <FOKO_TERRITORY_IDENTIFIER> 0:1 | |||
1 _FCTRY <FOKO_STATE_IDENTIFIER> 0:1 | |||
1 _FOKOID <FOKO_IDENTIFIER> 0:1 | |||
1 MAP <GEOGRAPHICAL_COORDINATES> 0:M | |||
2 TYPE <GEOGRAPHICAL_COORDINATE_TYPE> 1:1 | |||
1 EVEN <EVENT_DETAIL> 0:M | |||
1 _LOC @<XREF:_LOC>@ 0:M | |||
2 TYPE <HIERARCHICAL_RELATIONSHIP> 1:1 | |||
2 DATE <DATE_VALUE> 0:1 | |||
2 SOUR <SOURCE_CITATION> 0:M | |||
1 _DMGD <DEMOGRAPHICAL_DATA> 0:M | |||
2 DATE <DATE_VALUE> 0:1 | |||
2 SOUR <SOURCE_CITATION> 0:M | |||
2 TYPE <TYPE_OF_DEMOGRAPICAL_DATA> 1:1 | |||
1 _AIDN <ADMINISTRATIVE_IDENTIFIER> 0:M | |||
2 DATE <DATE_VALUE> 0:1 | |||
2 <SOURCE_CITATION> 0:M | |||
2 TYPE <TYPE_OF_ADMINISTRATIVE_IDENTIFIER> 1:1 | |||
1 <<MULTIMEDIA_LINK>> 0:M | |||
</source> | |||
Um die Übersichtlichkeit zu verbessern, sind die Zeilen | |||
eingerückt. Bei der eigentlich Gedcom-Ausgabe soll dies nicht | |||
gemacht werden. | |||
==Individual Record und Family Record - Ereignisstruktur== | ==Individual Record und Family Record - Ereignisstruktur== | ||
Die Ereignisstruktur wird an allen Stellen, an denen Orte referenziert werden, um das Tag _LOC erweitert. | |||
<source lang="gedcom"> | |||
1 <EVENT> | |||
< | |||
1 | |||
2 DATE | 2 DATE | ||
2 PLAC | 2 PLAC <PLACE_STRUCTURE> 0:1 | ||
3 _LOC @ | 3 _LOC @<XREF:_LOC>@ 0:1 | ||
</ | </source> | ||
Der Ortsname kann im PLAC Tag aufgeführt sein, um die Kompatibilität zu GEDCOM 5.5 herzustellen. | |||
Importierende Programme, die die "EXTENDED LOCATIONS" verstehen, sollten den PLAC Eintrag ignorieren, wenn zusätzlich ein _LOC Tag vorhanden ist. | |||
==Individual Record== | ==Individual Record== | ||
Der Tag '''_GODP''' wird eingeführt, um die Information | |||
"Taufpaten einer Person" transportieren zu können. | |||
"Taufpaten einer Person" transportieren zu | 0 @XREF:INDI@ INDI | ||
.. | |||
1 CHR | |||
0 @XREF:INDI@ INDI | 2 _GODP <GODPARENTS> 0:M | ||
.. | .. | ||
1 CHR | Anmerkungen: Das Tag '''_GODP''' (= Godparents) sollte nur verwendet werden, wenn das exportierende Programm Paten in Textfeldern verwaltet und nicht als eigenständige Personen. | ||
2 _GODP <GODPARENTS> 0:M | |||
.. | |||
exportierende Programm Paten in Textfeldern verwaltet und nicht als | |||
==Family Record== | ==Family Record== | ||
Der Tag '''_WITN''' wird eingeführt, um die Information "Trauzeugen einer Ehe" transportieren zu können. | |||
0 @XREF:FAM@ FAM | |||
"Trauzeugen einer Ehe" transportieren zu | .. | ||
1 MARR | |||
0 @XREF:FAM@ FAM | 2 _WITN <WITNESSES> 0:M | ||
.. | .. | ||
1 MARR | Anmerkung: Der Tag '''_WITN''' (= Witnesses) sollte nur verwendet werden, wenn das exportierende Programm Trauzeugen in Textfeldern verwaltet, und nicht als eigenständige Personen. | ||
2 _WITN <WITNESSES> 0:M | |||
.. | |||
exportierende Programm Trauzeugen in Textfeldern verwaltet, und | |||
nicht als | |||
Der Tag '''ASSO''' wird mit der gleichen Wirkung, die er im Zusammenhang mit einem Individual Record hat, eingeführt. Er dient dazu, eine Ehe mit Personen aus der Datenbank zu verknüpfen. | |||
Beispiel : Trauzeugen, aber auch : Priester, Standesbeamte. | |||
==TYPE Subtag des EVEN Tags== | ==TYPE Subtag des EVEN Tags== | ||
Zeile 141: | Zeile 109: | ||
==TYPE Subtag des MARR Tags== | ==TYPE Subtag des MARR Tags== | ||
Um die beiden Ereignisse "standesamtliche Trauung" und "kirchliche Trauung" auseinanderhalten zu können, wird dieser (bereits in Gedcom 5.5 enthaltene) Tag mit zwei definierten Ausprägungen versehen : | |||
* RELI | |||
* CIVIL | |||
==Angabe von Personennamen== | ==Angabe von Personennamen== | ||
Die bisherige Angabe des Namens mit Kennzeichung des Nachnamens | |||
durch Schrägstriche ist unbefriedigend, da die Struktur des | durch Schrägstriche ist unbefriedigend, da die Struktur des | ||
Namens nur ungenügend abgebildet wird. | Namens nur ungenügend abgebildet wird. | ||
Das exportierende Programm legt alle Namens-Informationen in Tags unterhalb des '''NAME'''-Tag ab, ähnlich wie es die Gedcom 5.5 Spezifikation vorsieht. Allerdings ist es möglich, Vornamen in mehrere Bestandteile aufzuteilen, die jeweils ein eigenes '''GIVN'''-Tag bekommen. | |||
Tags unterhalb des | |||
'''NAME'''-Tag ab, ähnlich wie es die Gedcom 5.5 | |||
Spezifikation vorsieht. Allerdings ist es | |||
mehrere Bestandteile aufzuteilen, die jeweils ein eigenes | |||
'''GIVN'''-Tag bekommen. | |||
''' | ''Bei den '''GIVN'''-Tags handelt es sich um eine geordnete Sequenz!'' | ||
< | Zusätzlich kann unterhalb von '''2 GIVN''' ein Tag '''3 TYPE''' angegeben werden, dessen Wert die Art des Vornamens angibt, insbesondere einen ''Rufnamen'' kennzeichnet. | ||
< | <source lang="gedcom">1 NAME <NAME_PERSONAL> {1:1} | ||
2 NPFX <NAME_PIECE_PREFIX> {0:1} | |||
2 GIVN <NAME_PIECE_GIVEN> {0:N} | |||
3 TYPE <NAME_TYPE> {0:1} | |||
2 NICK <NAME_PIECE_NICKNAME> {0:1} | |||
2 SPFX <NAME_PIECE_SURNAME_PREFIX> {0:1} | |||
2 SURN <NAME_PIECE_SURNAME> {0:1} | |||
2 NSFX <NAME_PIECE_SUFFIX> {0:1} | |||
</source> | |||
'''NAME_TYPE''' kann folgende Ausprägungen haben: | '''NAME_TYPE''' kann folgende Ausprägungen haben: | ||
;RUF:Der Vornamensteil ist ein Rufname.</td> | |||
Beispiel: | |||
< | <source lang="gedcom">1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef /Pockenfurth/ | ||
1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef/Pockenfurth/ | |||
2 GIVN Hieronimus | 2 GIVN Hieronimus | ||
2 GIVN Ernst | 2 GIVN Ernst | ||
Zeile 224: | Zeile 145: | ||
2 GIVN Hermann-Josef | 2 GIVN Hermann-Josef | ||
2 SURN Pockenfurth | 2 SURN Pockenfurth | ||
</ | </source> | ||
== Übersicht der neuen Typen == | == Übersicht der neuen Typen == | ||
;ADMINISTRATIVE_IDENTIFIER: Eine Identifikation, die den Ort aus der Sicht verwaltender Behörden kennzeichnet. Zum Beispiel die Gemeindekennzahl. | |||
;DEMOGRAPHISCHE_DATEN: Eine Anzahl von Objekten, die in einer Erhebung festgestellt worden ist. Z.B. die Anzahl Haushalte. | |||
;EVENT_DETAIL: Hier gilt es, noch den TYPE Tag ein wenig festzulegen.z.B. Gründung, Aufgabe, Eroberung, Zerstörung, Eingemeindung | |||
;FOKO_POSTCODE: FOKO verwendet gelegentlich andere Postcodes als die amtlichen, deshalb die Trennung von "POST" | |||
;FOKO_IDENTIFIER: Der eindeutige Identifier für einen Ort in FOKO. | |||
;FOKO_STATE_IDENTIFIER: Die FOKO-bezogene Zugehörigkeit eines Ortes zu einem "Staat". | |||
;FOKO_TERRITORY_IDENTIFIER: Die FOKO-bezogene Zugehörigkeit eines Ortes zu einem "Territorium". | |||
;GEOGRAPHICAL_COORDINATES: Geographische Koordinaten. Das Format hängt vom '''TYPE''' ab : | |||
<pre> | <pre> | ||
1 MAP JO99HZ | 1 MAP JO99HZ | ||
2 TYPE MAIDENHEAD | 2 TYPE MAIDENHEAD | ||
</pre> | </pre> | ||
<pre> | <pre> | ||
1 MAP 50.1234N 128.9876E | 1 MAP 50.1234N 128.9876E | ||
2 TYPE DEGREE | 2 TYPE DEGREE | ||
</pre> | </pre> | ||
;GEOGRAPHICAL_COORDINATE_TYPE: | |||
* DEGREE : Das bekannte Koordinatensystem eines Globus, | |||
* MAIDENHEAD : der Maidenhead Locator | |||
;HIERARCHICAL_RELATIONSHIP: Bezeichnet den Typ der Beziehung eines Ortes zur nächsthöheren Gebietseinheit. Es kann die Zugehörigkeit eines Ortes zur Verbandgemeinde sein, oder die Zugehörigkeit der katholischen Gemeinde(n) zu einem Bistum. Auch der Fakt, dass dieser Ort eine Hugenottengründung ist, könnte damit beschrieben werden. Derzeit definiert: | |||
* [POLI,RELI,GEOG,CULT] politische, religiöse, geographische, kulturelle Zugehörigkeit eines Ortes zur nächsthöheren "Gebietseinheit". Diese nächsthöhere Gebietseinheit ist ebenfalls durch eine _LOC Struktur beschrieben, und kann ihrerseits wieder zu einer nächsthöheren Gebietseinheit gehören. | |||
;PLACE_NAME: Name eines Ortes im allgemeinen Sprachgebrauch, z.B. "Frankfurt". Wenn eine Familie auschliesslich in Hessen beheimatete war, erübrigt sich oft der Zusatz "am Main", wenn ein Geburtsort mit "Frankfurt" bezeichnet wird. | |||
;PLACE_NAME_ADDITION: Zusatz, um einen Ort genauer bezeichnen zu können: z.B. "an der Oder", oder "am Main". | |||
;POSTCODE: die amtliche Postleitzahl. | |||
;TYPE_OF_ADMINISTRATIVE_IDENTIFIER: Typ der verwaltungsmässigen Kennzeichnung: | |||
* [POLI,RELI] politische, (Gemeindekennzahl), religiöse, (gibt es sowas wie Gemeindenummern bei den Kirchen ?) | |||
;TYPE_OF_DEMOGRAPICAL_DATA: Typ der demographischen Angabe zu einem Ort. | |||
* HSHO : Haushalte | |||
* CITI : Einwohner | |||
[[en:Gedcom 5.5EL]] | [[en:Gedcom 5.5EL]] |
Aktuelle Version vom 17. Mai 2018, 12:49 Uhr
Hinweis auf neuere Vereinbarungen
Nach Abschluss der Arbeiten zu GEDCOM 5.5EL hat der Verein für Computergenealogie mit einer größeren Anzahl von Programmautoren eine erweiterte Arbeitsgruppe zur korrekten Interpretation des GEDCOM Standards 5.5.1 ins Leben gerufen, diese Arbeitsgruppe wurde als Gedcom-L bezeichnet. Die Gedcom-L hat neben vielen anderen Themen auch alle Punkte der GEDCOM 5.5EL aufgegriffen und an den Stellen auch modifiziert, wo die Lösungen der GEDCOM 5.5EL dem GEDCOM-Standard widersprachen. Der neue Stand der Vereinbarungen ist zu finden unter:
Die im nachfolgenden dargestellten Lösungen werden nur noch aus historischen Gründen gezeigt, sie sollten auf keinen Fall mehr in Genealogie-Programmen verwendet werden.
Spezifikation Gedcom 5.5EL
Die
- Hersteller der Genealogieprogramme
- und der Verein für Computergenealogie e.V.
schlagen gemeinsam folgende Erweiterung des GEDCOM 5.5 Standards vor:
High-Level-Entitiy "Location"
Die High Level Entity "Location" wird eingeführt mit folgender Struktur:
0 @P65@ _LOC
1 NAME <PLACE_NAME> 1:M
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION>
2 NAMC <PLACE_NAME_ADDITION> 0:1
2 _LANG <LANGUAGE> 0:1
1 _FPOST <FOKO_POSTCODE> 0:M
2 DATE <DATE_VALUE> 0:1
1 POST <POSTCODE> 0:M
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION> 0:M
1 _FSTAE <FOKO_TERRITORY_IDENTIFIER> 0:1
1 _FCTRY <FOKO_STATE_IDENTIFIER> 0:1
1 _FOKOID <FOKO_IDENTIFIER> 0:1
1 MAP <GEOGRAPHICAL_COORDINATES> 0:M
2 TYPE <GEOGRAPHICAL_COORDINATE_TYPE> 1:1
1 EVEN <EVENT_DETAIL> 0:M
1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> 1:1
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION> 0:M
1 _DMGD <DEMOGRAPHICAL_DATA> 0:M
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION> 0:M
2 TYPE <TYPE_OF_DEMOGRAPICAL_DATA> 1:1
1 _AIDN <ADMINISTRATIVE_IDENTIFIER> 0:M
2 DATE <DATE_VALUE> 0:1
2 <SOURCE_CITATION> 0:M
2 TYPE <TYPE_OF_ADMINISTRATIVE_IDENTIFIER> 1:1
1 <<MULTIMEDIA_LINK>> 0:M
Um die Übersichtlichkeit zu verbessern, sind die Zeilen eingerückt. Bei der eigentlich Gedcom-Ausgabe soll dies nicht gemacht werden.
Individual Record und Family Record - Ereignisstruktur
Die Ereignisstruktur wird an allen Stellen, an denen Orte referenziert werden, um das Tag _LOC erweitert.
1 <EVENT>
2 DATE
2 PLAC <PLACE_STRUCTURE> 0:1
3 _LOC @<XREF:_LOC>@ 0:1
Der Ortsname kann im PLAC Tag aufgeführt sein, um die Kompatibilität zu GEDCOM 5.5 herzustellen.
Importierende Programme, die die "EXTENDED LOCATIONS" verstehen, sollten den PLAC Eintrag ignorieren, wenn zusätzlich ein _LOC Tag vorhanden ist.
Individual Record
Der Tag _GODP wird eingeführt, um die Information "Taufpaten einer Person" transportieren zu können.
0 @XREF:INDI@ INDI .. 1 CHR 2 _GODP <GODPARENTS> 0:M ..
Anmerkungen: Das Tag _GODP (= Godparents) sollte nur verwendet werden, wenn das exportierende Programm Paten in Textfeldern verwaltet und nicht als eigenständige Personen.
Family Record
Der Tag _WITN wird eingeführt, um die Information "Trauzeugen einer Ehe" transportieren zu können.
0 @XREF:FAM@ FAM .. 1 MARR 2 _WITN <WITNESSES> 0:M ..
Anmerkung: Der Tag _WITN (= Witnesses) sollte nur verwendet werden, wenn das exportierende Programm Trauzeugen in Textfeldern verwaltet, und nicht als eigenständige Personen.
Der Tag ASSO wird mit der gleichen Wirkung, die er im Zusammenhang mit einem Individual Record hat, eingeführt. Er dient dazu, eine Ehe mit Personen aus der Datenbank zu verknüpfen.
Beispiel : Trauzeugen, aber auch : Priester, Standesbeamte.
TYPE Subtag des EVEN Tags
Der TYPE Subtag des EVEN Ereignisses erhält eine Liste von definierten Ereignissen:
- Jugendweihe
- Firmung
- Seligsprechung
- Hausname
- Bürgerort
Auf diese Weise wird am wenigsten stark in die bestehende Gedcom Definition eingegriffen.
TYPE Subtag des MARR Tags
Um die beiden Ereignisse "standesamtliche Trauung" und "kirchliche Trauung" auseinanderhalten zu können, wird dieser (bereits in Gedcom 5.5 enthaltene) Tag mit zwei definierten Ausprägungen versehen :
- RELI
- CIVIL
Angabe von Personennamen
Die bisherige Angabe des Namens mit Kennzeichung des Nachnamens durch Schrägstriche ist unbefriedigend, da die Struktur des Namens nur ungenügend abgebildet wird.
Das exportierende Programm legt alle Namens-Informationen in Tags unterhalb des NAME-Tag ab, ähnlich wie es die Gedcom 5.5 Spezifikation vorsieht. Allerdings ist es möglich, Vornamen in mehrere Bestandteile aufzuteilen, die jeweils ein eigenes GIVN-Tag bekommen.
Bei den GIVN-Tags handelt es sich um eine geordnete Sequenz!
Zusätzlich kann unterhalb von 2 GIVN ein Tag 3 TYPE angegeben werden, dessen Wert die Art des Vornamens angibt, insbesondere einen Rufnamen kennzeichnet.
1 NAME <NAME_PERSONAL> {1:1}
2 NPFX <NAME_PIECE_PREFIX> {0:1}
2 GIVN <NAME_PIECE_GIVEN> {0:N}
3 TYPE <NAME_TYPE> {0:1}
2 NICK <NAME_PIECE_NICKNAME> {0:1}
2 SPFX <NAME_PIECE_SURNAME_PREFIX> {0:1}
2 SURN <NAME_PIECE_SURNAME> {0:1}
2 NSFX <NAME_PIECE_SUFFIX> {0:1}
NAME_TYPE kann folgende Ausprägungen haben:
- RUF
- Der Vornamensteil ist ein Rufname.
Beispiel:
1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef /Pockenfurth/
2 GIVN Hieronimus
2 GIVN Ernst
3 TYPE RUF
2 GIVN -Rüdiger
2 GIVN Hermann-Josef
2 SURN Pockenfurth
Übersicht der neuen Typen
- ADMINISTRATIVE_IDENTIFIER
- Eine Identifikation, die den Ort aus der Sicht verwaltender Behörden kennzeichnet. Zum Beispiel die Gemeindekennzahl.
- DEMOGRAPHISCHE_DATEN
- Eine Anzahl von Objekten, die in einer Erhebung festgestellt worden ist. Z.B. die Anzahl Haushalte.
- EVENT_DETAIL
- Hier gilt es, noch den TYPE Tag ein wenig festzulegen.z.B. Gründung, Aufgabe, Eroberung, Zerstörung, Eingemeindung
- FOKO_POSTCODE
- FOKO verwendet gelegentlich andere Postcodes als die amtlichen, deshalb die Trennung von "POST"
- FOKO_IDENTIFIER
- Der eindeutige Identifier für einen Ort in FOKO.
- FOKO_STATE_IDENTIFIER
- Die FOKO-bezogene Zugehörigkeit eines Ortes zu einem "Staat".
- FOKO_TERRITORY_IDENTIFIER
- Die FOKO-bezogene Zugehörigkeit eines Ortes zu einem "Territorium".
- GEOGRAPHICAL_COORDINATES
- Geographische Koordinaten. Das Format hängt vom TYPE ab :
1 MAP JO99HZ 2 TYPE MAIDENHEAD
1 MAP 50.1234N 128.9876E 2 TYPE DEGREE
- GEOGRAPHICAL_COORDINATE_TYPE
- DEGREE : Das bekannte Koordinatensystem eines Globus,
- MAIDENHEAD : der Maidenhead Locator
- HIERARCHICAL_RELATIONSHIP
- Bezeichnet den Typ der Beziehung eines Ortes zur nächsthöheren Gebietseinheit. Es kann die Zugehörigkeit eines Ortes zur Verbandgemeinde sein, oder die Zugehörigkeit der katholischen Gemeinde(n) zu einem Bistum. Auch der Fakt, dass dieser Ort eine Hugenottengründung ist, könnte damit beschrieben werden. Derzeit definiert:
- [POLI,RELI,GEOG,CULT] politische, religiöse, geographische, kulturelle Zugehörigkeit eines Ortes zur nächsthöheren "Gebietseinheit". Diese nächsthöhere Gebietseinheit ist ebenfalls durch eine _LOC Struktur beschrieben, und kann ihrerseits wieder zu einer nächsthöheren Gebietseinheit gehören.
- PLACE_NAME
- Name eines Ortes im allgemeinen Sprachgebrauch, z.B. "Frankfurt". Wenn eine Familie auschliesslich in Hessen beheimatete war, erübrigt sich oft der Zusatz "am Main", wenn ein Geburtsort mit "Frankfurt" bezeichnet wird.
- PLACE_NAME_ADDITION
- Zusatz, um einen Ort genauer bezeichnen zu können: z.B. "an der Oder", oder "am Main".
- POSTCODE
- die amtliche Postleitzahl.
- TYPE_OF_ADMINISTRATIVE_IDENTIFIER
- Typ der verwaltungsmässigen Kennzeichnung:
- [POLI,RELI] politische, (Gemeindekennzahl), religiöse, (gibt es sowas wie Gemeindenummern bei den Kirchen ?)
- TYPE_OF_DEMOGRAPICAL_DATA
- Typ der demographischen Angabe zu einem Ort.
- HSHO : Haushalte
- CITI : Einwohner