GEDCOM 5.5EL: Unterschied zwischen den Versionen

aus GenWiki, dem genealogischen Lexikon zum Mitmachen.
Zur Navigation springen Zur Suche springen
K (Internlink GEDCOM eingefügt)
K (Schützte „GEDCOM 5.5EL“: Aktualisierung durchgeführt ([edit=sysop] (unbeschränkt) [move=sysop] (unbeschränkt)))
 
(34 dazwischenliegende Versionen von 9 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 DYNAS-TREE, GES-2000, GF-Ahnen, PC-Ahnen und der Verein
'''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.'''
f&uuml;r Computergenealogie e.V. schlagen gemeinsam folgende Erweiterung des [[GEDCOM]] 5.5 Standards vor:</p>




==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 class="code">
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 class="code">
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 class="code">
1 CHR
0 @XREF:INDI@ INDI
2 _GODP &lt;GODPARENTS&gt; 0:M
..
..
1 _GODP &lt;PATEN&gt; 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.
</pre>
<div class="frame note">
<div class="label">Note</div>
<div class="content">Der Tag "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
"Treuzeugen einer Ehe" transportieren zu k&ouml;nnen.</p>
..
<pre class="code">
1 MARR
0 @XREF:FAM@ FAM
2 _WITN &lt;WITNESSES&gt; 0:M
..
..
1 _WITN &lt;WITNESSES&gt; 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.
</pre>
<div class="frame note">
 
<div class="label">Note</div>
<div class="content">Der Tag "Wittnesses" 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==
<div style="margin-left: 0 ; border: 2px">
Der '''TYPE''' Subtag des '''EVEN''' Ereignisses erhält eine Liste von definierten Ereignissen:
<p>Der '''TYPE''' Subtag des '''EVEN''' Ereignisses erh&auml;lt eine Liste
* Jugendweihe
  von definierten Ereignissen:
* Firmung
  <ul>
* Seligsprechung
 
* Hausname
   
* Bürgerort
<li>Jugendweihe</li>
   
<li>Firmung</li>
   
<li>Seligsprechung</li>
   
<li>Hausname</li>
   
<li>B&uuml;rgerort</li>
 
 
</ul>
</p>
<p>Auf diese Weise wird am wenigsten stark in die bestehende
  Gedcom Definition eingegriffen.</p>
</div>


Auf diese Weise wird am wenigsten stark in die bestehende Gedcom Definition eingegriffen.


==TYPE Subtag des MARR Tags==
==TYPE Subtag des MARR Tags==
<div style="margin-left: 0 ; border: 2px">
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 :  
<p>Um die beiden Ereignisse "standesamtliche Trauung" und
* RELI
  "kirchliche Trauung" auseinanderhalten zu k&ouml;nnen, wird
* CIVIL
  dieser (bereits in Gedcom 5.5 enthaltene) Tag mit zwei
  definierten Auspr&auml;gungen versehen :  
  <ul>
   
<li>RELI</li>
 
   
<li>CIVIL</li>
 
</ul>
</p>
</div>
 
 


==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&auml;gstriche ist unbefriedigend, da die Struktur des
Namens nur ungenügend abgebildet wird.
Namens nur ungen&uuml;gend abgebildet wird.</p>
 
<p>Das exportierende Programm legt alle Namens-Informationen in
Tags unterhalb des
'''NAME'''-Tag ab, &auml;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&auml;tzlich kann unterhalb von
'''2 GIVN''' ein Tag


'''3 TYPE''' angegeben werden, dessen Wert die Art des
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.  
Vornamens angibt, insbesondere einen
<em>Rufnamen</em> kennzeichnet.</p>
<pre class="code">
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>
''Bei den '''GIVN'''-Tags handelt es sich um eine geordnete Sequenz!''
<p>


'''NAME_TYPE''' kann folgende Auspr&auml;gungen haben:
Zusätzlich kann unterhalb von '''2 GIVN''' ein Tag '''3 TYPE''' angegeben werden, dessen Wert die Art des Vornamens angibt, insbesondere einen ''Rufnamen'' kennzeichnet.
<table class="ForrestTable" cellspacing="1" cellpadding="4">
<source lang="gedcom">1 NAME <NAME_PERSONAL>  {1:1}
 
2 NPFX <NAME_PIECE_PREFIX> {0:1}
<tr>
2 GIVN <NAME_PIECE_GIVEN>  {0:N}
   
3 TYPE <NAME_TYPE> {0:1}
<th>Wert</th>
2 NICK <NAME_PIECE_NICKNAME>  {0:1}
    <th>Bedeutung</th>
2 SPFX <NAME_PIECE_SURNAME_PREFIX> {0:1}
 
2 SURN <NAME_PIECE_SURNAME> {0:1}
2 NSFX <NAME_PIECE_SUFFIX> {0:1}
</source>


</tr>
'''NAME_TYPE''' kann folgende Ausprägungen haben:
 
;RUF:Der Vornamensteil ist ein Rufname.</td>
<tr>
   
<td>RUF</td>
    <td>Der Vornamensteil ist ein Rufname.</td>
 
</tr>


</table>
Beispiel:
</p>
<p>Beispiel:</p>
<pre class="code">


1 NAME Hieronimus Ernst-R&uuml;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
3 TYPE RUF
3 TYPE RUF
2 GIVN -R&uuml;diger
2 GIVN -Rüdiger
2 GIVN Hermann-Josef
2 GIVN Hermann-Josef
2 SURN Pockenfurth
2 SURN Pockenfurth
</pre>
</source>
</div>
 
 
 
==&Uuml;bersicht der neuen Typen==
<div style="margin-left: 0 ; border: 2px">
<dl>
   
<dt>ADMINISTRATIVE_IDENTIFIER</dt>
   
 
<dd>
     
<p>Eine Identifikation, die den Ort aus der Sicht
      verwaltender Beh&ouml;rden kennzeichnet. Zum Beispiel die
      Gemeindekennzahl.</p>
   
</dd>
   
<dt>DEMOGRAPHISCHE_DATEN</dt>
   
<dd>
     
<p>Eine Anzahl von Objekten, die in einer Erhebung
      festgestellt worden ist. Z.B. die Anzahl Haushalte.</p>
   
</dd>
 
   
<dt>EVENT_DETAIL</dt>
   
<dd>
     
<p>Hier gilt es, noch den TYPE Tag ein wenig festzulegen.z.B.
      Gr&uuml;ndung, Aufgabe, Eroberung, Zerst&ouml;rung,
      Eingemeindung,</p>
   
</dd>
   
<dt>FOKO_POSTCODE</dt>
   
<dd>
 
     
<p>FOKO verwendet gelegentlich andere Postcodes als die
      amtlichen, deshalb die Trennung von "POST".</p>
   
</dd>
   
<dt>FOKO_IDENTIFIER</dt>
   
<dd>
     
<p>Der eindeutige Identifier f&uuml;r einen Ort in FOKO.</p>
   
</dd>
   
 
<dt>FOKO_STATE_IDENTIFIER</dt>
   
<dd>
     
<p>Die FOKO-bezogene Zugeh&ouml;rigkeit eines Ortes zu einem
      "Staat".</p>
   
</dd>
   
<dt>FOKO_TERRITORY_IDENTIFIER</dt>
   
<dd>
     
<p>Die FOKO-bezogene Zugeh&ouml;rigkeit eines Ortes zu einem
      "Territorium".</p>


   
== Übersicht der neuen Typen ==
</dd>
;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.
<dt>GEOGRAPHICAL_COORDINATES</dt>
;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"
<dd>
;FOKO_IDENTIFIER: Der eindeutige Identifier für einen Ort in FOKO. 
     
;FOKO_STATE_IDENTIFIER: Die FOKO-bezogene Zugehörigkeit eines Ortes zu einem "Staat".
<p>Geographische Koordinaten. Das Format h&auml;ngt vom '''TYPE'''
;FOKO_TERRITORY_IDENTIFIER: Die FOKO-bezogene Zugehörigkeit eines Ortes zu einem  "Territorium".
      ab :
;GEOGRAPHICAL_COORDINATES: Geographische Koordinaten. Das Format hängt vom '''TYPE''' ab :
     
<pre>
<pre class="code">
1 MAP JO99HZ  
1 MAP JO99HZ  
2 TYPE MAIDENHEAD
2 TYPE MAIDENHEAD
</pre>
</pre>
 
<pre>
 
<pre class="code">
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


</p>
[[en:Gedcom 5.5EL]]
   
</dd>


<dt>GEOGRAPHICAL_COORDINATE_TYPE</dt>


<dd>
[[Kategorie:Software-Hintergrund]]
 
[[Kategorie:GEDCOM]]
<p>
   
 
<ul>
     
<li>DEGREE : Das bekannte Koordinatensystem eines
      Globus,</li>
     
<li>MAIDENHEAD : der Maidenhead Locator</li>
   
</ul>
 
</p>
 
</dd>
 
<dt>HIERARCHICAL_RELATIONSHIP</dt>
 
<dd>
 
<p>Bezeichnet den Typ der Beziehung eines Ortes zur
  n&auml;chsth&ouml;heren Gebietseinheit. Es kann die
  Zugeh&ouml;rigkeit eines Ortes zur Verbandgemeinde sein, oder die
  Zugeh&ouml;rigkeit der katholischen Gemeinde(n) zu einem Bistum.
  Auch der Fakt, dass dieser Ort eine Hugenottengr&uuml;ndung ist,
  k&ouml;nnte damit beschrieben werden. Derzeit definiert :</p>
 
</dd>
 
<dt>[POLI,RELI,GEOG,CULT]</dt>
 
<dd>
 
 
<p>politische, religi&ouml;se, geographische, kulturelle
  Zugeh&ouml;rigkeit eines Ortes zur n&auml;chsth&ouml;heren
  "Gebietseinheit". Diese n&auml;chsth&ouml;here Gebietseinheit ist
  ebenfalls durch eine _LOC Struktur beschrieben, und kann
  ihrerseits wieder zu einer n&auml;chsth&ouml;heren Gebietseinheit
  geh&ouml;ren.</p>
 
</dd>
   
<dt>PLACE_NAME</dt>
 
   
<dd>
     
<p>Name eines Ortes im allgemeinen Sprachgebrauch, z.B.
      "Frankfurt". Wenn eine Familie auschliesslich in Hessen
      beheimatete war, er&uuml;brigt sich oft der Zusatz"am Main",
      wenn ein Geburtsort mit "Frankfurt" bezeichnet wird.</p>
   
</dd>
   
<dt>PLACE_NAME_ADDITION</dt>
   
<dd>
     
<p>Zusatz, um einen Ort genauer bezeichnen zu k&ouml;nnen :
      z.B. "an der Oder", oder "am Main".</p>
 
   
</dd>
   
<dt>POSTCODE</dt>
   
<dd>
     
<p>die amtliche Postleitzahl.</p>
   
</dd>
   
<dt>RUFNAMENINDEX</dt>
   
<dd>
 
     
<p>Bezeichnung, der wievielte Vornamen aus einer NAME-Zeile
      der Rufname ist. Default : 1.</p>
   
</dd>
   
<dt>TYPE_OF_ADMINISTRATIVE_IDENTIFIER</dt>
   
<dd>
     
<p>Typ der verwaltungsm&auml;ssigen Kennzeichnung :</p>
   
</dd>
   
 
<dt>[POLI,RELI]</dt>
   
<dd>
     
<p>politische, (Gemeindekennzahl), religi&ouml;se, (gibt's
      sowas wie Gemeindenummern bei den Kirchen ?)</p>
   
</dd>
   
<dt>TYPE_OF_DEMOGRAPICAL_DATA</dt>
   
<dd>
     
<p>Typ der demographischen Angabe zu einem Ort.</p>
 
   
</dd>
 
<dt>[HSHO,CITI]</dt>
 
<dd>
 
<p>
   
<ul>
     
<li>HSHO : Haushalte</li>
     
<li>CITI : Einwohner</li>
 
   
</ul>
 
</p>
 
</dd>
 
 
</dl>
</div>
 
[[en:Gedcom 5.5EL]]

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