Gedcom 5.5EL

From GenWiki

Jump to: navigation, search

Contents

Deprecated

After completing work on GEDCOM 5.5EL, the Computer Genealogy Association has started a larger working group to correctly interpret the GEDCOM Standard 5.5.1 with a larger number of program authors. This working group was called Gedcom-L. The Gedcom-L has picked up on many other topics as well as all points of the GEDCOM 5.5EL and also modified where the GEDCOM 5.5EL solutions contradicted the GEDCOM standard.

The solutions presented below are presented for historical reasons only, they should by no means be used in genealogy programs.


Authors of genealogy programs Ages!, DYNAS-TREE, GES-2000, GF-Ahnen, PC-Ahnen, GEDCOM 2 Map and the Society For Computer Genealogy suggest together following proposal of an extension of the GEDCOM 5.5 standard called "Gedcom 5.5EL":

High-Level-Entitiy "Location"

The High Level Entity "Location" is introduced of following structure: 

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

To improve the readability lines are inserted. This should (and will) not be performed at real Gedcom-output.

Individual Record und Family Record - event structure

The event structure will be enhanced by the tag _LOC at all situations, where locations have to be referenced. 

1 <EVENT> 
2 DATE 
2 PLAC <PLACE_STRUCTURE> 0:1
3 _LOC @<XREF:_LOC>@ 0:1

The name of location can be additionally documented using the tag PLAC to ensure compatibility with GEDCOM 5.5 .

Programs that perform correct import of "EXTENDED LOCATIONS" should ignore PLAC entries in situations when a _LOC tag can be found.

Individual Record

We introduce Tag _GODP to cover information about a godfather (godparents) of a child that is baptized. 

0 @XREF:INDI@ INDI
..
1 CHR
2 _GODP <GODPARENTS> 0:M
..

Tag _GODP (= Godparents) should be used only in cases where the exporting programm handle information about a godfather in text fields and not in a separate person record.

Family Record

We introduce tag _WITN to cover information about a witness (whitnesses) of a marriage. 

0 @XREF:FAM@ FAM
..
1 MARR
2 _WITN <WITNESSES> 0:M
..

Tag _WITN (= Witnesses) should be used only in cases where the exporting programm handle information about a witness of a marriage in text fields and not in a separate person record.


Family Record

We introduce tag ASSO with the same intended effect as it has in the context with an individual record. It concanates a marriage record with person records from the data base, e.g. witnesses of a marriage or beyond that priests and registrars.

TYPE Subtag of the EVEN Tag

TYPE Subtag of the EVEN events gets a list of predefined events:

  • civic initiation ceremony
  • confirmation
  • beatification
  • Hausname (local name)
  • Bürgerort (a special location name in Suisse)


Thus we achive the least changes on the current GEDCOM definition.


TYPE Subtag of the MARR Tag

To distinguish between events "marriage ceremony in a registry office" and "marriage ceremony in a church" we extend the existing GEDCOM 5.5 tag MARR with two predefined subtags:

  • RELI


  • CIVIL

Names of a Person

Existing form of name records, framing last name with slashes is unsatisfying. Lost of information about the remaining name structure is evident.

Exporting program has to store all name information in tags following the NAME tag, similar the GEDCOM 5.5 specification requires. But we allow now to split names in seperate parts, each in an own GIVN tag. GIVN tags are an ordered (!) sequence.

In addition to that we allow to add under a 2 GIVN tag a 3 TYPE tag to store the type of this name part, particularly to mark the first name, that often is not the first name in the name order.

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 can be of following values:

value contents
RUF This part of the name is a first name.

Example:


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

New Types

ADMINISTRATIVE_IDENTIFIER

Identifier for a location with the intention of an administrative authority, e.g. Gemeindekennzahl (community identifier).

DEMOGRAPHISCHE_DATEN

A number of objects, during an ascertainment, e.g. the count of households.

EVENT_DETAIL

Here remains some work to define TYPE tags, e.g. foundation, abandonment, conquest, destruction, integration in an other community.

FOKO_POSTCODE

Sometimes FOKO (German data base Forscherkontakte = Researcher Contacts) uses other ZIP codes as the official post codes are, that´s why this special tag different to "POST".

FOKO_IDENTIFIER

The unique identifier of a location in the FOKO data base.

FOKO_STATE_IDENTIFIER

Affiliation of a location to a "state" in FOKO.

FOKO_TERRITORY_IDENTIFIER

Affiliation of a location to a "territory" in FOKO.

GEOGRAPHICAL_COORDINATES

Geographical coordinates. Data format depends on TYPE: 

1 MAP JO99HZ 
2 TYPE MAIDENHEAD

1 MAP 50.1234N 128.9876E
2 TYPE DEGREE

GEOGRAPHICAL_COORDINATE_TYPE

  • DEGREE : Well known coordinate system of a globe,
  • MAIDENHEAD : the Maidenhead Locator

HIERARCHICAL_RELATIONSHIP

Describes the type of a relation of a location to the hierarchically next higher area unit. This can be the affiliation of communities to a conglomerat or the affiliation of the catholic community to a diocese. Here, for example, you can store the fact, that this location was founded by the Huguenots. To this time we have:

[POLI,RELI,GEOG,CULT]

Political, religious, geographical, cultural affiliation of a location to the hierarchically next higher area unit. This "next higher area unit" is likewise described using a _LOC structure and can affiliate on its part to another "next higher area unit".

PLACE_NAME

Name of a location in common linguistic usage, e.g. "Frankfurt". If a familiy was located only in Hesse (state of Germany where Frankfurt am Main is located) the official add-on "am Main" (at river Main) is usually missed.

PLACE_NAME_ADDITION

Add-on to describe the location exactly, e.g. "an der Oder" or "am Main" (in Germany there are "Frankfurt an der Oder" /at river Oder/ and "Frankfurt am Main" /at river Main/)

POSTCODE

The official ZIP code.

RUFNAMENINDEX

The position of the first name in a NAME value string. Default is: 1.

TYPE_OF_ADMINISTRATIVE_IDENTIFIER

Type of administrative identifier:

[POLI,RELI]

political, (community), religious identifier (The question remains: Is there any similar identifier for churches?)

TYPE_OF_DEMOGRAPICAL_DATA

Type of demographical data of a location.

[HSHO,CITI]

  • HSHO : households
  • CITI : inhabitants, citizens


Retrieved from "http://wiki-en.genealogy.net/Gedcom_5.5EL"