GEDCOM 5.5EL: Unterschied zwischen den Versionen

aus GenWiki, dem genealogischen Lexikon zum Mitmachen.
Zur Navigation springen Zur Suche springen
K (Schützte „GEDCOM 5.5EL“: Aktualisierung durchgeführt ([edit=sysop] (unbeschränkt) [move=sysop] (unbeschränkt)))
 
(21 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''(BITTE!! Wenn an diesem Artikel geändert wird, bitte auch die [http://en.wiki.genealogy.net/index.php/Gedcom_5.5EL englische Version] entsprechend anpassen! DANKE!!)'''
{{Infobox|'''(Bitte!''' Wenn an diesem Artikel geändert wird, bitte auch die [[:en:Gedcom_5.5EL|englische Version]] entsprechend anpassen! Danke!)'''}}


=Spezifikation Gedcom 5.5EL=


==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]]


<p>Die Hersteller der Genealogieprogramme Ages!, DYNAS-TREE, GES-2000, GF-Ahnen, PC-Ahnen, GEDCOM 2 Map und der Verein f&uuml;r Computergenealogie e.V. schlagen gemeinsam folgende Erweiterung des [[GEDCOM]] 5.5 Standards vor:</p>
'''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.'''




==High-Level-Entitiy "Location"==
=Spezifikation Gedcom 5.5EL=
<div style="margin-left: 0 ; border: 2px">
<p>Die High Level Entity "Location" wird eingef&uuml;hrt mit
folgender Struktur:</p>
<pre>
0 @P65@ _LOC
  1 NAME &lt;PLACE_NAME&gt; 1:M
      2 DATE &lt;DATE_VALUE&gt; 0:1
      2 SOUR &lt;SOURCE_CITATION&gt;


      2 NAMC &lt;PLACE_NAME_ADDITION&gt; 0:1
Die
      2 _LANG &lt;LANGUAGE&gt; 0:1
* Hersteller der Genealogieprogramme
  1 _FPOST &lt;FOKO_POSTCODE&gt; 0:M
**[[Ages!]],
      2 DATE &lt;DATE_VALUE&gt; 0:1
**[[DYNAS-TREE]],
  1 POST &lt;POSTCODE&gt; 0:M
**[[GES-2000]],
      2 DATE &lt;DATE_VALUE&gt; 0:1
**[[GF-Ahnen]],
      2 SOUR &lt;SOURCE_CITATION&gt; 0:M
**[[PC-Ahnen]],
  1 _FSTAE &lt;FOKO_TERRITORY_IDENTIFIER&gt; 0:1
**[[GEDCOM 2 Map]]
  1 _FCTRY &lt;FOKO_STATE_IDENTIFIER&gt; 0:1
* und der [[Verein für Computergenealogie e.V.]]
  1 _FOKOID &lt;FOKO_IDENTIFIER&gt; 0:1
schlagen gemeinsam folgende Erweiterung des [[GEDCOM]] 5.5 Standards vor:
  1 MAP &lt;GEOGRAPHICAL_COORDINATES&gt; 0:M
      2 TYPE &lt;GEOGRAPHICAL_COORDINATE_TYPE&gt; 1:1
  1 EVEN &lt;EVENT_DETAIL&gt; 0:M
  1 _LOC @&lt;XREF:_LOC&gt; 0:M
      2 TYPE &lt;HIERARCHICAL_RELATIONSHIP&gt; 1:1
      2 DATE &lt;DATE_VALUE&gt; 0:1
      2 SOUR &lt;SOURCE_CITATION&gt; 0:M
  1 _DMGD &lt;DEMOGRAPHICAL_DATA&gt; 0:M
      2 DATE &lt;DATE_VALUE&gt; 0:1
      2 SOUR &lt;SOURCE_CITATION&gt; 0:M
      2 TYPE &lt;TYPE_OF_DEMOGRAPICAL_DATA&gt; 1:1
  1 _AIDN &lt;ADMINISTRATIVE_IDENTIFIER&gt; 0:M
      2 DATE &lt;DATE_VALUE&gt; 0:1
      2 &lt;SOURCE_CITATION&gt; 0:M
      2 TYPE &lt;TYPE_OF_ADMINISTRATIVE_IDENTIFIER&gt; 1:1
  1 &lt;&lt;MULTIMEDIA_LINK&gt;&gt; 0:M


</pre>
==High-Level-Entitiy "Location"==
<div class="frame note">
Die High Level Entity "Location" wird eingeführt mit folgender Struktur:
<div class="label">Note</div>
<source lang="gedcom">0 @P65@ _LOC
<div class="content">Um die &Uuml;bersichtlichkeit zu verbessern, sind die Zeilen
  1 NAME <PLACE_NAME> 1:M
einger&uuml;ckt. Bei der eigentlich Gedcom-Ausgabe soll dies nicht
      2 DATE <DATE_VALUE> 0:1
gemacht werden.</div>
      2 SOUR <SOURCE_CITATION>
</div>
      2 NAMC <PLACE_NAME_ADDITION> 0:1
</div>
      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==
<div style="margin-left: 0 ; border: 2px">
Die Ereignisstruktur wird an allen Stellen, an denen Orte referenziert werden, um das Tag _LOC erweitert.
<p>Die Ereignisstruktur wird an allen Stellen, an denen Orte
<source lang="gedcom">
  referenziert werden, um das Tag _LOC erweitert.</p>
1 <EVENT>
 
<pre>
1 &lt;EVENT&gt;
2 DATE  
2 DATE  
2 PLAC &lt;PLACE_STRUCTURE&gt; 0:1
2 PLAC <PLACE_STRUCTURE> 0:1
3 _LOC @&lt;XREF:_LOC&gt;@ 0:1
3 _LOC @<XREF:_LOC>@ 0:1
</pre>
</source>
<p>Der Ortsname kann im PLAC Tag aufgef&uuml;hrt sein, um die
  Kompatibilit&auml;t zu GEDCOM 5.5 herzustellen.</p>
<div class="frame note">
<div class="label">Note</div>
 
<div class="content">Importierende Programme, die die "EXTENDED LOCATIONS"
  verstehen, sollten den PLAC Eintrag ignorieren, wenn
  zus&auml;tzlich ein _LOC Tag vorhanden ist.</div>
</div>
</div>


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==
<div style="margin-left: 0 ; border: 2px">
Der Tag '''_GODP''' wird eingeführt, um die Information
<p>Der Tag '''_GODP''' wird eingef&uuml;hrt, um die Information
"Taufpaten einer Person" transportieren zu können.
"Taufpaten einer Person" transportieren zu k&ouml;nnen.</p>
0 @XREF:INDI@ INDI
 
..
<pre>
1 CHR
0 @XREF:INDI@ INDI
2 _GODP &lt;GODPARENTS&gt; 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 &lt;GODPARENTS&gt; 0:M
..
</pre>
<div class="frame note">
<div class="label">Note</div>
<div class="content">Der Tag '''_GODP''' (= Godparents) sollte nur verwendet werden, wenn das
exportierende Programm Paten in Textfeldern verwaltet und nicht als
eigenst&auml;ndige Personen.</div>
</div>
</div>


==Family Record==
==Family Record==
<div style="margin-left: 0 ; border: 2px">
Der Tag '''_WITN''' wird eingeführt, um die Information "Trauzeugen einer Ehe" transportieren zu können.
<p>Der Tag '''_WITN''' wird eingef&uuml;hrt, um die Information
0 @XREF:FAM@ FAM
"Trauzeugen einer Ehe" transportieren zu k&ouml;nnen.</p>
..
<pre>
1 MARR
0 @XREF:FAM@ FAM
2 _WITN &lt;WITNESSES&gt; 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 &lt;WITNESSES&gt; 0:M
..
</pre>
<div class="frame note">
 
<div class="label">Note</div>
<div class="content">Der Tag '''_WITN''' (= Witnesses) sollte nur verwendet werden, wenn das
exportierende Programm Trauzeugen in Textfeldern verwaltet, und
nicht als eigenst&auml;ndige Personen.</div>
</div>
</div>
 
==Family Record==
<div style="margin-left: 0 ; border: 2px">
<p>Der Tag '''ASSO''' wird mit der gleichen Wirkung, die er im
  Zusammenhang mit einem Individual Record hat, eingef&uuml;hrt. Er
  dient dazu, eine Ehe mit Personen aus der Datenbank zu
  verkn&uuml;pfen. Beispiel : Trauzeugen, aber auch : Priester,
  Standesbeamte.</p>
 
</div>


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 , wird dieser (bereits in Gedcom 5.5 enthaltene) Tag mit zwei definierten Ausprägungen versehen :  
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
* RELI
* CIVIL
* CIVIL


==Angabe von Personennamen==
==Angabe von Personennamen==
<div style="margin-left: 0 ; border: 2px">
Die bisherige Angabe des Namens mit Kennzeichung des Nachnamens
<p>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.</p>
Namens nur ungenügend abgebildet wird.


<p>Das exportierende Programm legt alle Namens-Informationen in
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 m&ouml;glich, Vornamen in
mehrere Bestandteile aufzuteilen, die jeweils ein eigenes  
'''GIVN'''-Tag bekommen.  
<em>Bei den
'''GIVN'''-Tags handelt es sich um eine geordnete
Sequenz!</em>
</p>
<p>Zusätzlich kann unterhalb von
'''2 GIVN''' ein Tag


'''3 TYPE''' angegeben werden, dessen Wert die Art des
''Bei den '''GIVN'''-Tags handelt es sich um eine geordnete Sequenz!''
Vornamens angibt, insbesondere einen
<em>Rufnamen</em> kennzeichnet.</p>
<pre>
1 NAME &lt;NAME_PERSONAL&gt;  {1:1}
2 NPFX &lt;NAME_PIECE_PREFIX&gt;  {0:1}
2 GIVN &lt;NAME_PIECE_GIVEN&gt;  {0:N}
3 TYPE &lt;NAME_TYPE&gt; {0:1}
2 NICK &lt;NAME_PIECE_NICKNAME&gt;  {0:1}
2 SPFX &lt;NAME_PIECE_SURNAME_PREFIX&gt;  {0:1}
2 SURN &lt;NAME_PIECE_SURNAME&gt;  {0:1}
2 NSFX &lt;NAME_PIECE_SUFFIX&gt;  {0:1}


</pre>
Zusätzlich kann unterhalb von '''2 GIVN''' ein Tag '''3 TYPE''' angegeben werden, dessen Wert die Art des Vornamens angibt, insbesondere einen ''Rufnamen'' kennzeichnet.
<p>
<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:  
<table class="ForrestTable" cellspacing="1" cellpadding="4">
;RUF:Der Vornamensteil ist ein Rufname.</td>
 
<tr>
   
<th>Wert</th>
    <th>Bedeutung</th>
 
 
</tr>
 
<tr>
   
<td>RUF</td>
    <td>Der Vornamensteil ist ein Rufname.</td>
 
</tr>


</table>
Beispiel:
</p>
<p>Beispiel:</p>
<pre>


1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef/Pockenfurth/
<source lang="gedcom">1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef /Pockenfurth/
2 GIVN Hieronimus
2 GIVN Hieronimus
2 GIVN Ernst
2 GIVN Ernst
Zeile 210: Zeile 145:
2 GIVN Hermann-Josef
2 GIVN Hermann-Josef
2 SURN Pockenfurth
2 SURN Pockenfurth
</pre>
</source>
</div>


== Übersicht der neuen Typen ==
== Übersicht der neuen Typen ==

Aktuelle Version vom 17. Mai 2018, 12:49 Uhr

Info
(Bitte! Wenn an diesem Artikel geändert wird, bitte auch die 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 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

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

en:Gedcom 5.5EL