GEDCOM/ LOC-Tag

Name und Bedeutung

Tag

_LOC

Formelle Bezeichnung

LOCATION

Deutsche Bezeichnung

Ortsobjekt

Verwendung

Das Kennzeichen _LOC dient dazu, die Daten eines Ortes, an dem ein Ereignis stattfand, in einem eigenen Datensatz zusammenzufassen.

Formale Beschreibung zulässiger Werte

Basis dieser Beschreibung: GEDCOM Standard Draft 5.5.1

Aussagen des GEDCOM Standards

Orte werden über das Kennzeichen PLAC beschrieben. Dieses Kennzeichen ist im GEDCOM Standard nicht ausreichend, um die Daten einer hierarchischen Struktur, die historischen Zusammenhänge zwischen verschiedenen Orten und ihren übergeordneten Verwaltungseinheiten, geographischen Einheiten oder die Strukturen von Kirchenhierarchien darzustellen.

Daher haben die Mitglieder der Gedcom-L Arbeitsgruppe zunächst unter dem Kennzeichen PLAC die Einführung eines Nutzerdefinierten Kennzeichens _LOC vereinbart, welches auf der Ebene 0 zur Ausgabe eines Datensatzes für ein Ortsobjekt verwendet wird. Diese Datensätze werden als dem Kennzeichen PLAC untergeordnete Zeilen referenziert:

...
2 PLAC Musterort
3 _LOC @P1@
...
0 @P1@ _LOC
1 NAME Musterort
...

Die beiden Kennzeichen PLAC und _LOC sind eng miteinander verbunden. Die Verwendung von _LOC in anderen Datensätzen (unter dem Kennzeichen PLAC) wird weiter im Artikel zu PLAC beschrieben.

Dieser Artikel dient der Weiterentwicklung und Präzisierung der Vereinbarungen zu den Ortsdatensätzen.

Vereinbarungen zu _LOC

Die folgenden Vereinbarungen wurden aus der Diskussion in der Gedcom-L abgeleitet und durch Abstimmung unter den an der Diskussion beteiligten Programmautoren der Gedcom-L verabschiedet. Der hier dokumentierte Stand enthält bislang die im August 2013 vereinbarten Änderungen und Ergänzungen zu PLAC/P4, hier als_LOC/L1 geführt; sowie die Vereinbarung PLAC/P7, hier jetzt als L2 geführt. In 2019 sind die Vereinbarungen präzisiert und teilweise auch modifiziert worden. Diese Änderungen aus 2019 sind in L1 bis L3 eingearbeitet.

L1 Ortsdatensätze

Zur Beschreibung einer umfangreichen Ortsverwaltung wird in Anlehnung an GEDCOM 5.5 EL die Verwendung von Ortsdatensätzen zugelassen:

Auf den Ortsdatensatz wird verwiesen durch folgende, unter PLAC angeordnete Zeile:

+1 _LOC @<XREF:_LOC>@

wobei für <XREF:_LOC> die Form @Pnnn@ empfohlen wird mit nnn als einer positiven, ganzen Zahl.

Der Ortsdatensatz selbst wird wie folgt strukturiert:

0 @<XREF:_LOC>@ _LOC
1 NAME <PLACE_NAME> {1:M}
2 DATE <DATE_VALUE> {0:1}
2 ABBR <ABBREVIATION_OF_NAME> {0:M}
3 TYPE <TYPE_OF_ABBREVIATION> {0:1}
2 LANG <LANGUAGE_ID> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 TYPE <TYPE_OF_LOCATION> {0:M}
2 _GOVTYPE <GOVID_OF_TYPE> {0:1}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _POST <POSTAL_CODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _GOV <GOV_IDENTIFIER> {0:1}
1 MAP {0:1}
2 LATI <PLACE_LATITUDE> {1:1}
2 LONG <PLACE_LONGITUDE> {1:1}
1 _MAIDENHEAD <MAIDENHEAD_LOCATOR> {0:1}
1 RELI <DENOMINATION> {0:1}
1 EVEN [<EVENT_DESCRIPTOR>|<NULL>] {0:M}
2 <<EVENT_DETAIL>> {0:1}
1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {0:1}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _DMGD <DEMOGRAPHICAL_DATA> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<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}
1 <<NOTE_STRUCTURE>> {0:M}
1 <<SOURCE_CITATION>> {0:M}
1 <<CHANGE_DATE>> {0:1}

L2 Formalisierung: Aufnahme LOCATION_RECORD in die Definition von RECORD

In die Definition des RECORD im GEDCOM-Standard 5.5.1 wird der Ortsdatensatz <<LOCATION_RECORD>> wie folgt aufgenommen:

   RECORD:= 
   [ 
   n <<FAM_RECORD>> {1:1} 
   | 
   n <<INDIVIDUAL_RECORD>> {1:1} 
   | 
   n <<MULTIMEDIA_RECORD>> {1:1} 
   | 
   n <<NOTE_RECORD>> {1:1} 
   | 
   n <<REPOSITORY_RECORD>> {1:1} 
   | 
   n <<SOURCE_RECORD>> {1:1} 
   | 
   n <<SUBMITTER_RECORD>> {1:1}
   |
   n <<LOCATION_RECORD>> {1:1}
   ]

L3 Detailangaben zum Ortsdatensatz (L1)

Der Übersicht halber werden alle Definitionen aufgeführt, wobei Zitate aus dem Standard mit der Seitenzahl aus der Übersetzung von Jörn Daub gekennzeichnet sind.

<ABBREVIATION_OF_NAME> ABBREVIATION_OF_NAME:= {Size=1:20} Abkürzung zum Ortsnamen, wobei die Art der Abkürzung mit dem optionalen TYPE weiter erläutert werden kann

<ADMINISTRATIVE_IDENTIFIER> ADMINISTRATIVE_IDENTIFIER:= {Size=1:35} amtliche oder öffentliche Kennung für ein Ortsobjekt, wie z.B. Gemeindekennzahl, ISO 3166 für Länder und Staaten.

<<CHANGE_DATE>> … S. 31

<DATE_VALUE> DATE_VALUE:= {Size=1:35} [ <DATE> | <DATE_PERIOD> | <DATE_RANGE>| <DATE_APPROXIMATED> | INT <DATE> (<DATE_PHRASE>) | (<DATE_PHRASE>) ] (Datum, Wert) … S. 47 Im _LOC Datensatz dienen die DATE dazu, die Gültigkeitsdauer der übergeordneten Eigenschaft festzulegen. Das trifft z.B. zu, wenn Orte zu bestimmten Zeitpunkten neue Namen bekamen, oder der Typ des Objektes wechselte (z.B. Erteilung der Stadtrechte). Bei Postleitzahlen hat mehrfach das System gewechselt, so dass jede PLZ eine Gültigkeitsdauer von … bis … hat (bis kann leer sein, wenn heute noch gültig). Bei demografischen Daten dient DATE dazu, den Zeitpunkt der Erhebung anzugeben.

<DEMOGRAPHICAL_DATA> DEMOGRAPHICAL_DATA:= {Size=1:120} Demografische Daten zu den Personen zum Ortsobjekt, wie Anzahl Haushalte, Anzahl Personen, Berufe usw.

<EVENT_DESCRIPTOR> EVENT_DESCRIPTOR:= {Size=1:90} (Ereignis, Bezeichner) Text, der ein die Person oder Familie [hier: Ortsobjekt] betreffendes bestimmtes Ereignis beschreibt. … S. 48

<<EVENT_DETAIL>> EVENT_DETAIL := … S. 38

<GOV_IDENTIFIER> GOV_IDENTIFIER:= {Size=1:12} ID des Objekts im Geschichtlichen Ortsverzeichnis (GOV), siehe [1] Die GOV-ID hat z.B. die Form CREGENJO52HG für Cremlingen. Eine Auflistung der GOV-ID steht über die miniGOV-Dateien zur Verfügung (Download über [2] ) oder online über die Webservice des GOV-Systems [3].

<GOVID_OF_TYPE> GOVID_OF_TYPE:= {Size=1:3} als einer ganzzahligen, positiven Zahl, wie sie im GOV System definiert ist. Die Definition im GOV System [4]ist verbindlich für die Interpretation dieser Zeile und erlaubt eine Interpretation der übergeordneten Zeile 1 TYPE für alle im GOV-System hinterlegten Sprachen. Hierfür steht auch die mehrsprachige RDF-Datei mit den Definitionen der Objekttypen des GOV-Systems zur Verfügung [5].

<HIERARCHICAL_RELATIONSHIP> <HIERARCHICAL_RELATIONSHIP>:= [POLI|RELI|GEOG|CULT] um damit politische (verwaltungsmäßige), kirchliche, geografische oder kulturelle Zuordnungen zu differenzieren. http://wiki-de.genealogy.net/GEDCOM/PLAC-Tag#Vereinbarungen_zu_PLAC, P4

<LANGUAGE_ID> LANGUAGE_ID:= {Size=1:15} (Sprach-Identifikation) Eine Liste von gültigen Sprachidentifikationscodes in lateinischer Schrift, … S. 50. Abweichend von der Aussage des Standards, dass andere Sprachen bis zur Einführung von UNICODE nicht unterstützt werden, werden alle dort aufgeführten Sprachen zugelassen.

<MAIDENHEAD_LOCATOR> MAIDENHEAD_LOCATOR:= {Size=1:8} Der Maidenhead Locator teilt die Welt in kleine, durch 8 Buchstaben und Ziffern gekennzeichnete Flächen (Mikrofelder), siehe [6]

<<MULTIMEDIA_LINK>> … S. 36

<<NOTE_STRUCTURE>> … S. 36

<PLACE_LATITUDE> PLACE_LATITUDE:= {Size=5:10} (Ort, Breitengrad) … S. 58. Die im Standard genannte maximale Größe von 8 Zeichen ist für die übliche Auflösung von GPS-Koordinaten zu klein, und wird daher hier durch 10 Zeichen ersetzt.

<PLACE_LONGITUDE> PLACE_LONGITUDE:= {Size=5:11} (Ort, Längengrad) Ein Wert, der den Längengrad eines Ortes angibt. Der Längengrad ist in Grad mit Nachkommastellen östlich oder westlich des Nullmeridians (Greenwich). Beispiel: 168 Grad, 9 Minuten und 3.4 Sekunden östlicher Breite würde formatiert als E168.150944. … S. 58. Die im Standard genannte maximale Größe von 8 Zeichen ist für die übliche Auflösung von GPS-Koordinaten zu klein, sie widerspricht auch unmittelbar dem dort genannten Beispiel. Sie wird daher hier durch 11 Zeichen ersetzt.

<PLACE_NAME> PLACE_NAME:= {Size=1:120} [ <PLACE_TEXT> | <PLACE_TEXT>, <PLACE_NAME> ] (Ortsname) … S.58

<POSTAL_CODE> POSTAL_CODE:= {Size=1:10} Postleitzahl, im Standard ADDRESS_POSTAL_CODE genannt [sollte in unserer Vereinbarung angepasst werden!] … S. 41

<DENOMINATION> DENOMINATION := {SIZE=1:30} Konfession des Ortsobjektes. Zu verwenden insbesondere bei Kirchen und Objekten der Kirchenorganisationen. Die Angabe kann Klartext sein wie vom Anwender eingegeben, oder aber zur Internationalisierung sprachunabhängig aus der Liste der Abkürzungen für Konfessionen gewählt werden ([7] oder konfession.csv auf [8]).

{Redaktioneller Hinweis: Die Datei konfession.csv soll in eine mehrsprachige Form überführt werden und dann an anderer Stelle neu angeboten werden. Der Link wird dann redaktionell geändert}<<SOURCE_CITATION>> … S. 38

<TYPE_OF_ABBREVIATION> TYPE_OF_ABBREVIATION:= {Size=1:20} Art der Abkürzung, z.B. ISO 3166

<TYPE_OF_ADMINISTRATIVE_IDENTIFIER> TYPE_OF_ADMINISTRATIVE_IDENTIFIER:= {Size=1:35} Art der amtlichen oder öffentlichen Kennung

<TYPE_OF_DEMOGRAPICAL_DATA> TYPE_OF_DEMOGRAPICAL_DATA:= {Size=1:35} Art der demografischen Daten

<TYPE_OF_LOCATION> TYPE_OF_LOCATION:= {Size=1:35} Art des Ort-Objektes. Empfohlen wird die Verwendung der Objekttypen des GOV-Systems, [9] Die Liste kann man sich auch über den Webservice des GOV mit der Funktion getTypeDescription abholen, sie steht auch -mehrsprachig- als RDF-Datei zur Verfügung [10].

Änderungen zu _LOC (2020)

Die Diskussion um die Ortsdatensätze wird auch in 2020 weiter geführt. Folgende Themen stehen an:

Abbildung flacher Ortsverwaltungen

Die Vereinbarungen zu _LOC sehen eine hierarchische Struktur vor, in der jede Ebene über das eingebaute Kennzeichen 1 _LOC zu einer nächsthöheren Ebene weiterverweisen kann. Die Diskussion dreht sich nun um die Frage, wie Programme, die nur "flache" Ortshierarchien unterstützen, ihre Daten exportieren sollen. Eine "flache" Ortshierarchie ist dadurch gekennzeichnet, dass in jeder Ebene maximal eine nächsthöhere Ebene zur Verfügung steht - und somit jeder Ort genau eine Gesamthierarchie hat.

Möglich sind bislang:

• der Export über die vereinbarten _LOC Datensätze, wobei maximal auf einen nächsthöheren Datensatz verwiesen wird
• der Export über die im Standard festgelegte Version, nach der die Hierarchien in nach Ebene sortierter und mit Kommata abgetrennter Reihenfolge dargestellt wird, wobei in einem PLAC.FORM die dargestellten Hierarchieebenen definiert werden.

Es wird von einigen Programmentwicklern vorgeschlagen, neben diesen beiden heute bereits per Standard bzw. per Vereinbarung zu _LOC möglichen Wegen einen weiteren Weg zu vereinbaren, der mit Sonderkennzeichen im _LOC Datensatz erlaubt, neben der aktuell dargestellten Hierarchiestufe auch gleich alle weiteren Stufen einzubauen, ohne auf die 1 _LOC Verweise zuzugreifen.

Beispiel GEDCOM Standard 5.5.1:

2 PLAC Musterort, Musterkreis, Musterland, Musterstaat
3 FORM place, county, state, country

Beispiel mit 1 _LOC (verabschiedet):

2 PLAC Musterort
3 _LOC @P1@
0 @P1@ _LOC
1 NAME Musterort
2 TYPE Ort
1 _LOC @P2@
0 @P2@ _LOC
1 NAME Musterkreis
2 TYPE Kreis
1 _LOC @P3@
0 @P3@ _LOC
1 NAME Musterland
2 TYPE Land
1 _LOC @P4@
0 @P4@ _LOC
1 NAME Musterstaat
2 TYPE Staat

Vorschlag einer weiteren Struktur:

2 PLAC Musterort
3 _LOC @P1@
0 @P1@ _LOC
1 NAME Musterort
2 TYPE Ort
1 _STAE Musterland
1 _CTRY Musterstaat

Diskussionsbeiträge

• Die vorgeschlagene weitere Struktur ist in dieser Form bereits von wenigen Programmen verwendet worden, allerdings mit den inzwischen veralteten FOKO-Zeigern _FSTAE und _FCTRY, die per Abstimmung in 2019 aus dem Ortsdatensatz entfernt wurden. Sie sind damit zwar programmspezifisch weiterhin möglich, aber nicht mehr gemeinsam von der Gedcom-L Gruppe empfohlen.
• Die verabschiedete Struktur mit den hierarchischen Datensätzen sieht zwar hier zunächst kompliziert aus - das relativiert sich ganz schnell, wenn weitere Orte auf denselben Kreis zugreifen und dann die gesamte Struktur oberhalb des Ortes einschließlich des Kreises ja schon zur Verfügung steht und nicht noch einmal angelegt werden muss.
• Die vorgeschlagene neue Struktur mit nicht-hierarchischen Ortsdatensätzen ist unflexibel: Neben _STAE und _CTRY müssten weitere Kennzeichen eingesetzt werden, um solche Ebenen wie Kreis, Amt oder Bezirk abzubilden. Sie ist allerdinsg sehr eng an die Ortsverwaltung einiger Programme angelehnt, so dass diese Programme einen einfacheren Export und Import realisieren könnten.
• Die Vereinfachung für die erwähnten Programme relativiert sich aber sehr schnell: Da die GEDCOM Standard Lösung schon immer zur Verfügung stand, und die hierarchische Ortsdatenstruktur verabschiedet ist, müssten diese Programme ihren Import ohnehin auf diese beiden Versionen einstellen. Es bliebe bei dem Vorteil, einen einfachen Export gestalten zu können. Dagegen gibt es Widerstand, weil dann die anderen Programme für die vereinbarten Datenaustauschwege diese zusätzliche Möglichkeit in ihren Import einbauen müssten.

Status: In kontroverser Dikussion, Entscheidung im Rahmen einer weiteren Abstimmrunde angestrebt.

Fehlende Kennzeichen im _LOC Datensatz

Nach dem bisherigen Entscheidungsstand können nicht alle mit dem GEDCOM-Standard darstellbaren Informationen auch strukturiert in einem Ortsdatensatz dargestellt werden. Während unter PLAC die Kennzeichen FORM, FONE, FONE.TYPE, ROMN und ROMN.TYPE explizit erlaubt sind, können diese im Gegensatz zu MAP, MAP.LATI, MAP.LONG und der <<NOTE_STRUCTURE>> bislang im Ortsdatensatz nicht untergebracht werden.

Es wird diskutiert, diese Kennzeichen auch unter _LOC im Datensatz zuzulassen. Dies entspräche der Vorgehensweise bei MAP und NOTE, widerspricht aber eigentlich dem Grundsatz der Liste, mit Nutzerdefinierten Kennzeichen bzw. Strukturen keine Daten zu transportieren, die laut Standard bereits explizit strukturiert dargestellt werden können. Dem steht aber die deutlich effektivere Darstellung gegenüber, wenn man statt einer Wiederholung bei jedem PLAC Aufruf diese Information einmal gezielt unter 0 _LOC zur Verfügung stellt.

Status: In Diskussion

Zusammenhang zwischen aufrufendem PLAC und aufgerufenem _LOC Datensatz

Nach Veröffentlichung des ADDENDUMS zum 5.5.1 Standard durch die Gedcom-L Gruppe kam von der FHISO die gezielte Anfrage, wie denn der aufrufende PLAC und der aufgerufene _LOC Datensatz inhaltlich zusammenhängen. Dazu fehlen konkrete Vereinbarungen.

Seitens FHISO wird gefragt, ob folgendes erlaubt ist:

2 PLAC Delaware, USA
3 _LOC @P1@
0 @P1@ _LOC
1 NAME United States of America

Hier wird ein Ort mit einem Ortsdatensatz verknüpft, der offensichtlich ganz was anderes beschreibt. So geplant war es nicht, aber ausgeschlossen ist es durch die Vereinbarungen auch nicht.

In dem Zusammenhang tauchen weitere Fragen auf, ob folgendes innerhalb ein und derselben GEDCOM Datei erlaubt ist:

2 PLAC München
3 _LOC @P2@
...
2 PLAC Munich
3 _LOC @P2@
...
2 PLAC München,München,Bayern,Deutschland
3 FORM place,county,state,country
3 _LOC @P2@
...
0 @P2@ _LOC
1 NAME München
2 LANG German
1 NAME Munich
2 LANG English
1 NAME München,München,Bayern,Deutschland
...

Also konkret, ob verschiedene Ortsnamen unter PLAC, die aber hier offensichtlich dasselbe Ortsobjekt meinen, einen gemeinsamen Ortsdatensatz zitieren dürfen. Noch einfacher die Frage: Darf überhaupt der unter PLAC stehende Ortsname im _LOC Datensatz fehlen? Und darf unter NAME in einem _LOC auch die heierachische Struktur, kommata-getrennt nach dem GEDCOM Standard stehen (also das Beispiel: 1 NAME München,München,Bayern,Deutschland) ?

Das Bespiel mit München,München,Bayern,Deutschland legt nahe, dass der unter NAME in _LOC angegeben Wert auf jeden Fall von dem unter PLAC abweichen darf: Denn die logische Umsetzung der hierarchischen Ortsdatensätze verbannt ja Kreis, Land und Staat in die nächsthöhere Ebene. Aber auch diese Frage ist nicht diskutiert und somit auch nicht beantwortet worden.

Änderungen zu _LOC (2019)

Im Jahr 2019 wurden nach entsprechenden Diskussionen folgende Änderungen beschlossen, die daraufhin in L1 bis L3 eingearbeitet wurden:

L1.1 Entfall des Kennzeichens _NAMC

Das in Anlehnung an GEDCOM 5.5 EL vereinbarte Kennzeichen _NAMC unter NAME entfällt ersatzlos. Mit diesem Kennzeichen wurde in einigen Programmen eine Trennung des Ortsnamens in zwei Bestandteile durchgeführt, die diese Programme aber auch beim Import aus einem komplett angelieferten Ortsnamen in NAME bilden können. Wegen der Interpretationsschwierigkeiten in anderen Programmen soll daher der Ortsname komplett unter NAME exportiert werden.

L1.2 Einführung des Kennzeichens RELI im Ortsdatensatz

In L1 und L2 wird zusätzlich eingefügt:

1 RELI <DENOMINATION> {0:1}

mit <DENOMINATION> := SIZE{1:30} Konfession des Ortsobjektes. Zu verwenden insbesondere bei Kirchen und Objekten der Kirchenorganisationen. Die Angabe kann Klartext sein wie vom Anwender eingegeben, oder aber zur Internationalisierung sprachunabhängig aus der Liste der Abkürzungen für Konfessionen gewählt werden ([11] oder konfession.csv auf [12]).

{Redaktioneller Hinweis: Die Datei konfession.csv soll in eine mehrsprachige Form überführt werden und dann an anderer Stelle neu angeboten werden. Der Link wird dann redaktionell geändert}

L1.3 Änderung zur TYPE unter 1 _LOC

Bislang wurde vereinbart, dass bei Einsatz der Verbindung zur nächsthöheren Ortsobjektebene über 1 _LOC zwingend eine Zeile 2 TYPE folgen muss:

1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {1:1}

Da die Art dieser Verbindung aber aus der detaillierteren Beschreibung des zitierten Ortsobjekts auch hervorgeht und diese Information also redundant ist, wird sie in L1 auf eine optionale Ausgabe verändert:

1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {0:1}

L1.4 Entfall der FOKO Kennzeichen _FPOST, _FSTAE, _FCTRY

Das FOKO System ist inzwischen abgeschaltet, zum Teil auch die Dokumentation der verwendeten Bezeichnungen nicht mehr verfügbar. Aus diesem Grunde werden in L1 und L3 sowie in PLAC/P3 die Kennzeichen _FPOST, _FSTAE und _FCTRY entfernt.

siehe PLAC/P3 http://wiki-de.genealogy.net/GEDCOM/PLAC-Tag#Vereinbarungen_zu_PLAC, P3

L1.5 Aufnahme der GOV Objekttyp-ID

Zur sprachunabhängigen Identifikation der Objekttypen <TYPE_OF_LOCATION> wird ein Kennzeichen _GOVTYPE eingeführt, welches den Export der ID eines Ortsobjekttyps im GOV System [13] erlaubt. Dieses Kennzeichen wird im _LOC Datensatz dem Kennzeichen TYPE wie folgt unterstellt:

...
1 TYPE <TYPE_OF_LOCATION> {0:M}
2 _GOVTYPE <GOVID_OF_TYPE> {0:1}
...

mit <GOVID_OF_TYPE>:= {Size=1:3} als einer ganzzahligen, positiven Zahl, wie sie im GOV System definiert ist. Die Definition im GOV System [14]ist verbindlich für die Interpretation dieser Zeile und erlaubt eine Interpretation der übergeordneten Zeile 1 TYPE für alle im GOV-System hinterlegten Sprachen. Hierfür steht auch die mehrsprachige RDF-Datei mit den Definitionen der Objekttypen des GOV-Systems zur Verfügung [15].

Bei Annahme dieses Entscheidungsvorschlages werden L1 und L3 entsprechend erweitert.

Änderungsumfang zu _LOC L1 (PLAC P4) vom August 2013

Es wurden folgende Änderungen an der ursprünglichen Version von L1/P4 vereinbart. Die Änderungen sind in L1/P4 eingearbeitet, die Darstellung hier dient nur der Nachvollziehbarkeit der Änderungen.

L1/P4korr Ergänzungen und Korrekturen zu L1/P4

An der in Runde 1 verabschiedeten Vereinbarung L1 (P4) werden folgende Änderungen vorgenommen:

Der Ortsdatensatz erhält die Bezeichnung LOCATION_RECORD, damit wird der Definition in P4 vorangestellt: LOCATION_RECORD :=

Entfernen der Doppelnennung _FPOST:

• 1 _FPOST <FOKO_POSTCODE> {0:1}

stand neben

• 1 _FPOST <FOKO_POSTCODE> {0:M}

im Umfang des Ortsdatensatzes. Die erste Nennung soll gelöscht werden (ist in der Doku zu P4 bereits umgesetzt!).

Korrektur Quellenaufruf unter _DMGD:

1 _DMGD <DEMOGRAPHICAL_DATA> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
2 TYPE <TYPE_OF_DEMOGRAPICAL_DATA> 1:1

Korrektur EVEN:

1 EVEN [<EVENT_DESCRIPTOR>|<NULL>] {0:M}
2 <<EVENT_DETAIL>> {0:1}

Postleitzahl als Nutzerdefiniertes Kennzeichen (statt POST):

1 _POST <POSTAL_CODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}

Ergänzung untergeordneter Kennzeichen zu 1 TYPE sowie Zulassen mehrerer Vorkommen {1:M}:

1 TYPE <TYPE_OF_LOCATION> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}

Verwendung des TYPE unterhalb des datensatzinternen _LOC mit folgenden Ausprägungen: [POLI|RELI|GEOG|CULT] um damit politische (verwaltungsmäßige), kirchliche, geografische oder kulturelle Zuordnungen zu differenzieren. Näheres zum TYPE des zitierten übergeordneten Objektes regelt dann die 1 TYPE im aufgerufenen Datensatz.

Behandlung/Darstellung schwieriger Situationen

Diskussionsstand in der Arbeitsgruppe der Programmautoren (Runde 3, 2019)

Bei der Umsetzung der Ortsdatensätze in Programmen aus der Gedcom-L, aber auch weiterer Programme, kommen Fragen zu Konkretisierungen unserer Vereinbarung L1 hoch. Insbesondere die nähere Beschreibung der dort verwendeten Elemente wird nachgefragt.

Aus Runde 2 sind weitere Themen offen, da sie nicht bis zu einer Entscheidung diskutiert wurden. Diese Punkte sind jetzt hier aus dem Umfang der Runde 2 in den Umfang der Runde 3 verschoben worden.

Übersicht Themen in Runde 3

Themen in Bearbeitung:

• Konkretisierungen zur Vereinbarung L1 Ortsdatensätze
• Musterdatei, Teil PLAC und _LOC

Konkretisierungen zur Vereinbarung L1/P4 Ortsdatensätze

Die getroffene Vereinbarung zu Ortsdatensätzen L1 (P4) enthält neue Strukturelemente, die bislang nicht näher beschrieben sind. Außerdem enthält sie Stukturelemente, die zwar im GEDCOM-Standard definiert sind, die hier aber in anderem Kontext stehen und ggfs. eine andere Bedeutung haben. Somit betseht Bedarf, diese Elemente näher zu beschreiben.

Ein allererster Entwurf hierzu wurde zur Diskussion gestellt und als L2 als Entscheidungsvorschlag eingestellt.

Musterdatei, Teil PLAC und _LOC

Änderungen und Ergänzungen sind in der Arbeitsliste vorgeschlagen zu: - Aufname von ABBR, ABBR.TYPE, LANG in den _LOC Datensatz - Zitat geonames im _LOC Datensatz - Korrektur zwischen dargestellter Verwaltungsstruktur in PLAC und FORM

Diskussionsstand in der Arbeitsgruppe der Programmautoren (Runde 2, 2014)

Übersicht Themen in Runde 2

erledigte Themen:

• Formalisierung: Aufnahme LOCATION_RECORD in die Definition von RECORD
• Korrekturen/Ergänzungen zu Vereinbarung L1 (Ortsdatensätze)

Diskussionsstand in der Arbeitsgruppe der Programmautoren (beendete Runde 1)

3 Arten für den Export von PLAC

Die Autoren haben im Rahmen der Diskussion zu PLAC festgestellt, dass es drei verschiedene Stufen gibt, in welcher Tiefe Informationen zu PLAC nach GEDCOM exportiert werden:

I:

PLAC klartext

(keine weitere Struktur)

II:

PLAC strukturierter Text

FORM (gibt die Struktur an, normalerweise pauschal im Header erledigt)

III:

PLAC strukturierter Text

FORM (gibt die Struktur an, normalerweise pauschal im Header erledigt)

_LOC @Pnn@

mit Datensatz @Pnn@.

In allen drei Varianten können die Kennzeichen, die laut GEDCOM-Standard 5.5.1 unter PLAC stehen, eingebracht werden. Variante III ist eine Erweiterung des GEDCOM-Standards mit nutzerdefinierten Kennzeichen, oft den Vereinbarungen der GEDCOM 5.5 EL folgend.

Variante III wird hier mit betrachtet, weil der Standard für eine umfangreiche Ortsverwaltung nicht ausreichend Möglichkeiten bietet.

Anmerkungen zu GEDCOM 5.5. EL

Mit GEDCOM 5.5. EL wurde ein erster Anlauf gemacht, detaillierte und strukturierte Informationen zu Orten und deren Zuordnungen zu übergeordneten Verwaltungsstrukturen in GEDCOM darstellen zu können. Es besteht in der Gedcom-L weitgehende Einigkeit, für die strukturierte GEDCOM-Ausgabe solcher Ortsinformationen Ortsdatensätze einzuführen und sich dabei möglichst weitgehend an GEDCOM 5.5 EL anzulehnen, bei Abweichungen vom GEDCOM Standard 5.5.1 aber dem 5.5.1 Priorität einzuräumen.

Daher sind folgende Punkte diskutiert worden:

MAP: Die Verwendung von MAP muss den Vorgaben von 5.5.1 angepasst werden.

_FOKOID: Der Name FOKOID wird nicht mehr verwendet, er wurde durch GOV-Kennung ersetzt. Daher sollte _FOKOID in _GOV umbenannt werden

In GEDCOM 5.5 EL fehlt die Möglichkeit, neben den verschiedenen Namen auch Abkürzungen darzustellen

Ein Bespiel mit einer Darstellung als Ortsdatensatz (Entwurf)

Als Beispiel wird hier Weiskirchen, heute Ortsteil von Rodgau bei Offenbach/Main dargestellt.

Zunächst die Informationen aus GOV:

   WEIHEN_W6051
   gehört zu RODGAUJO40KA,
   hat ab 1993-07-01 PLZ 63110,
   hat bis 1993-06-30 PLZ W6051,
   heißt  (auf deu) Weiskirchen,
   ist (auf deu) Ort;

Das ist eine Beschreibung aus der "alten" GOV Zeit, ohne Koordinaten, mit 4-stelliger Postleitzahl. Die Koordinaten und der Locator sind also noch hinzuzufügen.

Für Rodgau liefert GOV:

   RODGAUJO40KA
   gehört zu adm_136438,
   hat ab 1993-07-01 PLZ 63110,
   hat bis 1993-06-30 PLZ W6054,
   hat externe Kennung  opengeodb:23189,
   heißt  (auf deu) Rodgau,
   ist (auf deu) Stadt (Siedlung),
   liegt bei 50.03°N 8.88°O;

Rodgau gehört zu Offenbach, und Offenbach zu Darmstadt (seit 1945) bzw zu Starkenburg (vor 1937), Details siehe GOV.

Damit sieht das Beispiel im Entwurf eines Ortsdatensatzes in GEDCOM in 2 Ebenen ( Ortsteil und Staft ) so aus:

0 @P1@ _LOC
1 NAME Weiskirchen
1 TYPE Ortsteil
1 POST 63110
2 DATE FROM 01 JUL 1993
1 POST W6051
2 DATE TO 30 JUN 1993
1 _GOV WEIHEN_W6051
1 MAP
2 LATI N50.050000
2 LONG E8.883333
1 _MAIDENHEAD JO40KB
1 _LOC @P2@
2 _TYPE Ort in Stadt
...
0 @P2@ _LOC
1 NAME Rodgau
1 TYPE Stadt
1 POST 63110
2 DATE FROM 01 JUL 1993
1 POST W6054
2 DATE TO 30 JUN 1993
1 _GOV RODGAUJO40KA
... usw

Bei der Postleitzahl POST ist schon mal die in GEDCOM 5.5. EL vorgesehene Möglichkeit genutzt, "alt" und "neu" durch das Datum genauer zu spezifizieren. Das geht mit vielen anderen Eigenschaften auch, insbesondere auch mit der verwaltungsmäßigen Zuordnung. Daher wurden auf der Ebene des Datensatzes für einen Ortsteil bewusst _FSTAE ( Hessen ) und _FCTRY ( Deutschland ) nicht verwendet, weil das über die Zuordnungskette mit _LOC @P2@ und weiteren übergeordneten Ebenen "automatisch" zu Hessen und Deutschland zugeordnet wird - mit dem großen Vorteil, dass frühere Zuordnungen vor der Zeit des Staates Deutschland ebenfalls richtig im System abgebildet sind, wenn die Aufrufe 1 _LOC @Pnnn@ mit einem 2 DATE <DATE_VALUE> richtig mit Zeiträumen jeweils belegt werden.