GEDCOM 5.5EL: Unterschied zwischen den Versionen

aus GenWiki, dem genealogischen Lexikon zum Mitmachen.
Zur Navigation springen Zur Suche springen
(→‎High-Level-Entitiy "Location": html-Kraut entfernt)
K (Schützte „GEDCOM 5.5EL“: Aktualisierung durchgeführt ([edit=sysop] (unbeschränkt) [move=sysop] (unbeschränkt)))
 
(12 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''(BITTE!! Wenn an diesem Artikel geändert wird, bitte auch die [[:en: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!)'''}}
 
 
==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=
=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:
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"==
==High-Level-Entitiy "Location"==
Die High Level Entity "Location" wird eingeführt mit folgender Struktur:
Die High Level Entity "Location" wird eingeführt mit folgender Struktur:
<gedcom>0 @P65@ _LOC
<source lang="gedcom">0 @P65@ _LOC
   1 NAME <PLACE_NAME> 1:M
   1 NAME <PLACE_NAME> 1:M
       2 DATE <DATE_VALUE> 0:1
       2 DATE <DATE_VALUE> 0:1
       2 SOUR <SOURCE_CITATION>
       2 SOUR <SOURCE_CITATION>
       2 NAMC <PLACE_NAME_ADDITION> 0:1
       2 NAMC <PLACE_NAME_ADDITION> 0:1
       2 _LANG <LANGUAGE> 0:1
       2 _LANG <LANGUAGE> 0:1
Zeile 25: Zeile 43:
       2 TYPE <GEOGRAPHICAL_COORDINATE_TYPE> 1:1
       2 TYPE <GEOGRAPHICAL_COORDINATE_TYPE> 1:1
   1 EVEN <EVENT_DETAIL> 0:M
   1 EVEN <EVENT_DETAIL> 0:M
   1 _LOC @<XREF:_LOC> 0:M
   1 _LOC @<XREF:_LOC>@ 0:M
       2 TYPE <HIERARCHICAL_RELATIONSHIP> 1:1
       2 TYPE <HIERARCHICAL_RELATIONSHIP> 1:1
       2 DATE <DATE_VALUE> 0:1
       2 DATE <DATE_VALUE> 0:1
Zeile 38: Zeile 56:
       2 TYPE <TYPE_OF_ADMINISTRATIVE_IDENTIFIER> 1:1
       2 TYPE <TYPE_OF_ADMINISTRATIVE_IDENTIFIER> 1:1
   1 <<MULTIMEDIA_LINK>> 0:M
   1 <<MULTIMEDIA_LINK>> 0:M
</gedcom>
</source>


Um die Übersichtlichkeit zu verbessern, sind die Zeilen
Um die Übersichtlichkeit zu verbessern, sind die Zeilen
Zeile 46: Zeile 64:
==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.
Die Ereignisstruktur wird an allen Stellen, an denen Orte referenziert werden, um das Tag _LOC erweitert.
<gedcom>
<source lang="gedcom">
1 <EVENT>
1 <EVENT>
2 DATE  
2 DATE  
2 PLAC <PLACE_STRUCTURE> 0:1
2 PLAC <PLACE_STRUCTURE> 0:1
3 _LOC @<XREF:_LOC>@ 0:1
3 _LOC @<XREF:_LOC>@ 0:1
</gedcom>
</source>


Der Ortsname kann im PLAC Tag aufgeführt sein, um die  Kompatibilität zu GEDCOM 5.5 herzustellen.
Der Ortsname kann im PLAC Tag aufgeführt sein, um die  Kompatibilität zu GEDCOM 5.5 herzustellen.
Zeile 91: 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
Zeile 105: Zeile 123:


Zusätzlich kann unterhalb von '''2 GIVN''' ein Tag '''3 TYPE''' angegeben werden, dessen Wert die Art des Vornamens angibt, insbesondere einen ''Rufnamen'' kennzeichnet.
Zusätzlich kann unterhalb von '''2 GIVN''' ein Tag '''3 TYPE''' angegeben werden, dessen Wert die Art des Vornamens angibt, insbesondere einen ''Rufnamen'' kennzeichnet.
<gedcom>1 NAME <NAME_PERSONAL>  {1:1}
<source lang="gedcom">1 NAME <NAME_PERSONAL>  {1:1}
2 NPFX <NAME_PIECE_PREFIX>  {0:1}
2 NPFX <NAME_PIECE_PREFIX>  {0:1}
2 GIVN <NAME_PIECE_GIVEN>  {0:N}
2 GIVN <NAME_PIECE_GIVEN>  {0:N}
Zeile 113: Zeile 131:
2 SURN <NAME_PIECE_SURNAME>  {0:1}
2 SURN <NAME_PIECE_SURNAME>  {0:1}
2 NSFX <NAME_PIECE_SUFFIX>  {0:1}
2 NSFX <NAME_PIECE_SUFFIX>  {0:1}
</gedcom>
</source>


'''NAME_TYPE''' kann folgende Ausprägungen haben:  
'''NAME_TYPE''' kann folgende Ausprägungen haben:  
Zeile 120: Zeile 138:
Beispiel:
Beispiel:


<gedcom>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 127: Zeile 145:
2 GIVN Hermann-Josef
2 GIVN Hermann-Josef
2 SURN Pockenfurth
2 SURN Pockenfurth
</gedcom>
</source>


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