Control the quality of your genealogy data
GEDCOM standard, structure of genealogy data. Data management and control.
The word Gedcom designates a genealogical data exchange format.
It was originally developed by the Mormon Church for religious reasons, then retrieved by genealogists to exchange genealogical data between people running their genealogy applications on incompatible computer systems.
So Gedcom is a kind of genealogical language. It is the most famous and used worldwide.
The word Gedcom, which is an acronym for Genealogical data communication, is spelled like an acronym: GEDCOM. By metonymic derivation, a Gedcom also designates a genealogy file in Gedcom format. The file you are working on within Ancestris is a Gedcom.
Since the mid-1990s, with the advent of the Internet and the proliferation of digital exchanges, the Gedcom specification has gradually become an essential standard for most genealogy software and sites worldwide.
However, while most of them can export in Gedcom format, some of them do not strictly respect the Gedcom format and make some adaptations by adding proprietary structures or using existing ones for different meanings. In some cases, proprietary data structures cannot be properly converted to the Gedcom format and some data might simply not be exported.
Ancestris is fully Gedcom compatible with Gedcom versions 5.5 and 5.5.1. As a user, you may safely rely on Ancestris to keep comprehensive genealogy files, without risk of data loss, and share or transmit them with anyone.
Characteristics of a Gedcom file
A Gedcom file is a text file, i.e. a file containing human readable lines of text, that can be opened and edited using any text editor, such as Notepad, Kate, Kwrite, Gedit, etc. Its extension name is "*.ged".
As a result, such a file can be used *as is* by any genealogy software, installed under any operating system, without any conversion need.
Each line of text starts with a number and a label. The label is called a "tag". This tag is made up of three or four capital letters. It defines the type of information that follows on the line.
- For example, the tag PLAC (= place) always indicates that the text that follows this tag is a place (such as place of birth, place of death, place of a ceremony, etc.)
Records of a Gedcom file
A Gedcom file contains a set of records. A record is a group of text lines, the first one of which starts with a zero "0". A record defines something in particular, which depends on the type of record.
The first and the last record of a Gedcom file are of particular types:
- The first record is called the header (HEAD tag) and defines some general information about the file.
- The last record is called the end of file trailer marker (TRLR tag). It defines the end of the file.
Each of the other records defines a genealogical entity, with its own set of tags.
A Gedcom file uses 7 entity categories. The records that can be found in a Gedcom file are therefore as follows:
- Records defining individuals (tag INDI)
- Records defining families (tag FAM)
- Records defining notes (tag NOTE)
- Records defining sources (tag SOUR)
- Records defining repositories (tag REPO)
- Records defining media files (tag OBJE)
- Records defining information submitters (tag SUBM)
The choice to consider these 7 categories of data as being records is arbitrary of course, but it is always the case when creating a standard.
One could easily imagine other types of records, such as places for example. The fact that a place is not a separate entity does not prevent Ancestris from managing them and respecting the Gedcom format at the same time.
Tree structure of a record
Each record is presented in a tree structure: each tag can include any number of sub-tags.
Hierarchical levels are numbered.
As each line must imperatively remain in its place from the point of view of the hierarchy, each of them is assigned a number corresponding to the level occupied in the tree structure of the record.
This is why the main level line of each record is level zero, numbered 0. A line located at the level immediately below bears the number 1. A line located at the level immediately below level 1 bears the number 2. And so on.
Identifier and entity records
As mentioned above, apart from HEAD and TRLR records, all the other records are entity records.
Each entity record starts with a level 0 line followed by the following:
- The ID number of the entity surrounded by two at-signs (@),
- The tag associated with the category to which the entity belongs.
- For example, the line "0 @I5@ INDI" is the first record line of an INDIvidual entity which ID is 'I5'.
For greater clarity, lines of a record can be indented so as to more clearly show the relationship between the lines of the record. The information lines underneath a tag qualify the tag.
- Non indented record:
0 @I5@ INDI => this defines indidual number 'I5' 1 NAME John Doe => The indivudual's name is John Doe 1 SEX M => This individual is a male 1 BIRT => What follows defines his birth event 2 DATE April 16, 1951 => John Doe was therefore born on April 16, 1951 1 FAMC @F1328@ => Family F1328 is the record that defines John Doe's family (FAM) where he is a child (C)
- Indented record:
0 @I5@ INDI => this defines indidual number 'I5' 1 NAME John Doe => The indivudual's name is John Doe 1 SEX M => This individual is a male 1 BIRT => What follows defines his birth event 2 DATE April 16, 1951 => John Doe was therefore born on April 16, 1951 1 FAMC @F1328@ => Family F1328 is the record that defines John Doe's family (FAM) where he is a child (C)
The Gedcom editor is an editor within Ancestris which shows you the exact information located in the Gedcom file and all of it. It also enhances the display of this information to make it even easier to read.
This editor uses an indented display and does not show level numbers. It also adds handles, to show or hide sub-tag levels, making it easy to expand or collapse any branch.
- This is how the same individual would show in the Gedcom editor:
As you can see, the Gedcom editor enhances the display by adding icons and by fetching relevant hints.
In particular, the "@F1328@" piece of data is replaced, only in the display, not in the real Gedcom file, with the relevant information about the family. Here, we therefore immediately know that John's parents are named Martin and Kelly.
Also the name is split into its lastname and firstname parts.
Line formatting inside a record
Each line in a record is made of 3 elements:
- The level number, from 0 to n,
- The tag which defines the type of genealogical information that follows,
- The genealogical information.
Example: the line
2 DATE April 16, 1951 means level 2, information of type DATE which value is 16 april 1951.
In order to know what this date refers to, you would have to read the previous lines. Knowing this is a level 2 line, there must be a level 1 (the event in this case) and a level 0 (the record entity) above.
Referencing another entity
Sometimes in a line, one may need to refer to another record entity. This is done using by indicating the identification number of the entity, surrounded by two at-signs (@).
The difference between reference "@id@" defining a record and reference "@id@" pointing to a record is the following:
- If the reference is in the 0-level record before the tag, right after the "0", then it is a definition of a record. Example :
0 @I5@ INDI: defines individual I5
- If the reference is on the right hand side of the tag, it references the entity. We also say it "points" towards the entity. Example, if we have this line inside an individual record:
1 FAMC @F1328@: this indicates that the family from which this person is a child (meaning of FAMC), is F1328. It also assumes that F1328 is defined somewhere else in the Gedcom file as a record which should start with
0 @F1328@ FAM.
The Gedcom standard refers to the set of rules that govern what can and cannot be done when writing a Gedcom file, so that everyone organizes genealogical information in the same, so that others can understand. It is therefore the grammar of the Gedcom language.
Two main standards exist, 5.5 and 5.5.1, the second being a slight evolution of the first one. Things permitted in the first are no longer permitted in the second, and vice versa. These differences are nevertheless limited.
Ancestris handles both 5.5 et 5.5.1. standards, and can convert your Gedcom file from one standard to the other and vice-versa.
This norm was released on January 2nd, 1996.
You will find details of the comprehensive Gedcom standard release 5.5 here in the form of an html site.
This norm was first released in 1999 as a draft and remained stable until November 15th, 2019 when it was made official.
You can also consult the Gedcom standard release 5.5.1 as a pdf file: Norme Gedcom 5.5.1.
These 20 years of stability makes this standard a very well documented and widely used way to exchange genealogical information.
Oddly enough, the two standards documentations are not available under the same format.
You will find in the 5.5.1 document a comparison between the two Gedcom standards.
An entity in the Gedcom standard is a main genealogical component such as an individual, a family, a source of information or a note. It can also be an multimedia object such as a video or a audio record.
In a Gedcom file, an entity is a record identified by an identification number and a group of tags specifying its characteristics.
The various genealogical characteristics associated with an entity are called properties: birth, marriage, date, place, event, text, address, etc.
Ancestris follows the Gedcom standard as closely as possible and uses the same concepts of entity and property.
The organization of information for each entity follows the precise grammar of the standard. This grammar provides several possibilities to store the information. To see these various possibilities in Ancestris, use the Gedcom editor.
The 7 categories of entities
There are seven categories of entities in the Gedcom standard. An entity always belongs to one, and only one, of these seven categories.
Each category has its dedicated properties. However, regardless of the category to which they belong, all entities operate according to the same principles. There are described below.
In Ancestris, all entities are easily accessible from the Entity Table.
An individual, or a person, is a human being, living or deceased. It is the primary component of any genealogy.
In the Gedcom standard, an individual is defined by the INDI tag, and has an identification number which could nearly be anything. In Ancestris, this ID starts with the letter I.
The main properties of an individual are:
- a name, made of a first name and a lastname, and possibily made of other name elements.
- events such as birth, marriage, occupation, and many others.
- relationships with other individuals in the genealogy.
Events and relationships are probably the most interesting parts of your genealogy because they are the pieces of information that will let you understand the life of your ancestors and the stories they could tell you.
NAME Lt. Cmndr. Joseph /Allen/ jr.
In this example jr. is considered the suffix of the name. All the information was entered only in the NAME tag without using any sub-tag.
The Gedcom standard provides a detailed structure to store the name of an individual, and specify all the possible elements of a name, in particular NICK and NSFX which are placed at the end of NAME.
- GIVN : (given name) First name. Its value must be identical to that in the NAME tag. It is an optional tag. The different first names are separated by a comma.
- NICK : (nick name) A familiar name or nickname, which is used in addition to, or instead of, the last name.
- NPFX : (name prefix) Name prefix. An element of the name that precedes the lastname (e.g. Master, General, Doctor, etc.)
- SPFX : (surname prefix) Particle before the Lastname. A complement to the name which is preceding the name, and which is not to be taken into account when sorting lastnames. Different articles / name prefixes are separated by a comma, for example in the name “de la Cruz”, this value must be “de, la”.
- SURN : (surname) Lastname at birth, family name. Different surnames are separated by a comma.
- NSFX : (name suffix) Lasname Suffix. A complement to the name, an article, which follows the last name, and which is not to be taken into account when sorting lastnames. Different name suffixes are separated by a comma. Example: eldest, son.
- NOTE : Note about the individual
- SOUR : Source of information proving the existence and the characteristics of the individual.
- ALIA : (alias) Link with another individual entity, indicating that this current individual could be a duplicate of the other one and that one of the two should be removed eventually. It does mean that the two persons are the same person with a different name. One should use two NAME tags for that, within one single individual entity.
A family is a couple of human beings, living or deceased, united either by a legal union (e.g. marriage) or by a de-facto union (e.g. co-living). Most often, one or more children are associated with it.
A family is therefore a structure bringing together two or more individuals (spouse, children) as well as a set of specific properties such as the various events associated with it (marriage, divorce, etc.)
In the Gedcom standard, a family is designated by the FAM tag and receives an ID number starting with the letter F in Ancestris.
A Media, or Multimedia Element is a photo, an audio or video document (a photograph, an audio recording, a film, a copy of a document, etc.) generally intended to be associated with one or more individuals or families or to be associated with a source.
In the Gedcom standard, a multimedia element is defined by the OBJE tag. It has an ID number starting with the letter M in Ancestris.
Warning ! There are two kinds of multimedia elements: the entity and the property. These two kinds of media, although they have the same tag (OBJE), should not be confused.
- The multimedia entity can be used by several other entities. It is therefore meant to be shared, collective or common. It is truly autonomous and can exist independently of the entities that refer to it. Example: a audio file specifying your analysis of a research involving several individuals.
- The multimedia property is intended to qualify a single piece of information of the genealogy. It can only be used once. It is useless when taken out of its context, its connection to the information to which it relates. Example: a video of a newly born child. The multimedia property, unlike the multimedia entity, does not receive any ID number and is only valid for a single property, in a given entity. It can only exist within the entity that includes it. If the entity is deleted, the property disappears with it.
In summary, if the same multimedia object must be assigned to several individuals, several families, etc., it is more efficient to store it in the form of a object entity. Once entered, it will be possible to use it an infinite number of times. As a object property, you would have to re-enter the link to the media file as many times as you would need it.
Warning ! Ancestris does not make any copy of your multimedia files. It just "refers" to the actual files. Ancestris will read them where you will need them in Ancestris. So please do not erase them thinking that Ancestris made a copy of them.
A note is a text information that can be associated with other categories of entities (individuals, families, multimedia elements, etc.) or with a property anywhere in the genealogy.
In the Gedcom standard, a note is defined by the tag NOTE and it has an ID number starting with the letter N in Ancestris.
Warning ! There are two kinds of notes: the entity and the property. These two kinds of notes, although they have the same tag (NOTE), should not be confused.
- The note entity can be used by several other entities. It is therefore meant to be shared, collective or common. It is truly autonomous and can exist independently of the entities that refer to it. Example: a text specifying your analysis of a research involving several individuals.
- The note property is intended to qualify a single piece of information of the genealogy. It can only be used once. It is useless when taken out of its context, its connection to the information to which it relates. Example: a characteristic of a newly born child. The note property, unlike the note entity, does not receive any ID number and is only valid for a single property, in a given entity. It can only exist within the entity that includes it. If the entity is deleted, the property disappears with it.
In summary, if the same note must be assigned to several individuals, several families, etc., it is more efficient to store it in the form of a note entity. Once entered, it will be possible to use it an infinite number of times. As a note property, you would have to re-enter the text of the note as many times as you would need it.
A source is anything that defines the origin of a piece information. It can be a document, a book, a monument, etc.
It can also be a natural person: your great-grandmother can, for example, be qualified as a source, if she has transmitted a family history to you orally for instance.
This entity is intended to collect very precisely the various references (document title, symbol, act number, page, etc.) in order to allow any subsequent verification of the characteristics of other entities (in particular, individuals and families).
In the Gedcom standard, a source is defined by the SOUR tag and it has an ID number starting with the letter S in Ancestris.
Sources maintain a close relationship with other entities, repositories. A repository contains sources, and sources are located in repositories. Please refer to the following section for detailed considerations on how to organze sources and repositories.
Warning ! There are two kinds of sources: the entity and the property. These two kinds of sources, although they have the same tag (SOUR), should not be confused.
- The source entity can be used by several other entities. It is therefore meant to be shared, collective or common. It is truly autonomous and can exist independently of the entities that refer to it. Example: a marriage deed.
- The source property is intended to qualify a single piece of information of the genealogy. It can only be used once. It is useless when taken out of its context, its connection to the information to which it relates. The source property, unlike the source entity, does not receive any ID number and is only valid for a single property, in a given entity. It can only exist within the entity that includes it. If the entity is deleted, the property disappears with it.
In summary, if the same source must qualify several events of individuals, families, etc., it is more efficient to store it in the form of a source entity. Once entered, it will be possible to use it an infinite number of times. As a source property, you would have to re-enter the characteristics of the source as many times as you would need it.
A submitter is a person who collects information to contribute to the construction of a genealogy file.
This person is likely to be one of the authors of the genealogy, or any genealogists likely to provide the Ancestris user with their genealogical information.
In the Gedcom standard, a submitter is defined by the SUBM tag and it has an ID number starting with the letter B in Ancestris.
A repository is a place where genealogy sources can be found (documents, books, audio recordings, films, etc.). It can be a physical building (e.g. archive, cemetery), or a website (e.g. the website of the archive service).
Repository entities maintain a close relationship with source entities. A repository is likely to contain several sources, a source belongs to a repository.
In the Gedcom standard, a repository is defined by the REPO tag and it has an ID number starting with the letter R in Ancestris.
The header entity is the first record of the Gedcom file. The header contains information about the file: version of the standard (5.5 or 5.5.1), the author of the file, structure of jurisdictions in places, etc.
Its creation is taken care of by Ancestris when creating a new file. You most probably will not need to change it after creation.
In Ancestris, it can be edited using the Menu > File > Properties. Refer to the File Properties page for more details.
Identification number of an entity
The ID number is an identification number assigned to each entity, within the same category. In order to avoid the creation of possible duplicates, this number is obviously unique.
Moreover, this particular number always has the same form, namely a letter followed by a certain number of digits. Each category of entity being associated with a particular letter, the first letter of the ID number indicates the category to which it belongs.
The user does not have to worry about assigning a new ID number when creating a new entity: this numbering is carried out automatically by Ancestris.
Note that in the Tools / Preferences / Editions / Identification number menu, a check box can be activated to reuse the ID numbers left available by entities that have been deleted.
Also, you can always change ID numbers later once entities have been created. Use the Generate ID Numbers tool for that.
A property if a piece of information describing a characteristic of an entity.
A property consists essentially of two elements: its name, identified by a TAG, and its VALUE.
Let's consider the following three properties.
- City : London
- City : Paris
- City : Rome
These three properties share the same name (City), but have different values: London, Paris and Rome.
The City is coded in the Gedcom file by the tag CITY, in capital letters.
The Gedcom standard defines a large number of genealogical properties.
Each of these properties is identified by a Tag, which make each of them unique and unambiguous.
Here are some examples of properties and their tags between parenthesis.
- Name (tag NAME)
- Date (tag DATE)
- Place (tag PLAC)
- Note (tag NOTE) - here we mean the NOTE property, not the NOTE entity.
- Sex (tag SEX)
- Birth (tag BIRT)
- Marriage (tag MARR)
- Death (tag DEAT)
- Occupation (tag OCCU)
- Religion (tag RELI)
- Residence (tag RESI)
For more details:
- For the properties available in a Gedcom file, see the Tags page
- About Dates, please read the Date page.
- About Places, please read the Places page.
- About Events, please read the Events page.
In the Gedcom file, properties always keep the same structure and follow strictly the same syntax rules.
In Ancestris, properties exactly correspond to the Gedcom properties, but they may look different depending on the view that displays them.
Properties in the Gedcom file
Each line of the Gedcom file is a property.
Each property line has the following format:
Number Tag Value
Number is the hierarchical level of the property as described in the Gedcom page.
2 DATE 27 SEP 1601
The first item is the number 2, indicating the level of the row in the record entity.
The second element is the DATE tag, indicating that the property is a date.
The third element is the value of the date (27 SEP 1601).
Therefore, the whole line means that the date of the genealogical element above this line, is September 27, 1601.
Properties in the Gedcom editor
The Gedcom editor displays property lines in a manner quite similar to that of the Gedcom file: one line per property, containing the tag followed by its value.
However, the following differences exist.
- The editor does not display the entire Gedcom file, but only one entity at a time: the ID number and the category of this entity appear on the first line, at the top
- To the left of the label (tag), there is a symbol in the form of a mini-icon referring to the nature of the tag. The mini-icons added to the tree view make it much easier to read compared to the raw Gedcom file.
- The editor does not display the line numbers, but represents them in a tree structure, with a more or less pronounced indentation depending on the situation of each line in the hierarchy. These lines are also provided with handles, which can expand or hide the subdivisions of a particular branch.
Properties in the other editors
In editors, properties are displayed in the user's language.
In the Aries and Cygnus editors, neither the labels, nor the lines, nor their tree structure appear: the name of each field, more explicit than a simple tag, simply invites the user to fill it in, as we fill in a form.
Properties in the Entities Table
In the Entity Table, each row represents an entity, and each column represents a property.
It is possible to configure the Table in order to choose the properties to display.
Properties displayed in windows
A tag is a property type identifyer.
The Gedcom standard defines a number of tags on three or four capital letters, taken from the English name of the property type.
For example, knowing that the SURN label means surname, the
SURN Martin property line can be translated as: the surname is "Martin".
You will find in this page the list of most common tags.
The Gedcom editor is the Ancestris window that shows best all the properties in your genealogy.
The icon next to a tag helps you know whether the tag complies to the Gedcom standard or not.
- , , , , , etc. : regular pre-defined tags. Therefore they are compliant with the Gedcom standard.
- : unknown tag, or at the wrong place.
- : user-defined tag : tags starting with the underscore "_" are user-defined tags. These tags can be added underneath any other tag in the Gedcom file. They are allowed.
- However, before creating a new tag, please check if the type of information is not already defined by the Gedcom standard. This will allow you to better exchange genealogical data. You can check predefined tag using the Gedcom editor.
- You may tell Ancestris, in the Preferences, when you use the Gedcom validation tool, whether to consider user-defined tags as erroneous or allowed.
- On rare occasions, Ancestris had to defined user-defined tags when the Gedcom standard did not plan for it (e.g. _SOSA for the SOSA numbering)
- : indicates a correct tag with an invalid value.
- , , : navigation tags: the " " symbol on the icon is specific to Ancestris and indicates a pointer to another entity. You can navigate to the entity indicated in this tag by jut clicking on it.
This first table is a description of the main tags.
||Tag||5.5.||5.5.1.||Description and usage
|Abbreviation||ABBR||X||X||A short name of a title, description, or name.|
|Adoption||ADOP||X||X||Pertaining to creation of a legally approved child-parent relationship that does not exist biologically.|
|Address||ADDR||X||X||The contemporary place, usually required for postal purposes, of an individual, a submitter of information, a repository, a business, a school, or a company.|
|Age||AGE||X||X||The age of the individual at the time an event occurred, or the age listed in the document.|
|Agency||AGNC||X||X||The institution or individual having authority and/or responsibility to manage or govern.|
|Alias||ALIA||X||X||An indicator to link different record descriptions of a person who may be the same person.|
|Annulment||ANUL||X||X||Declaring a marriage void from the beginning (never existed).|
|Associates||ASSO||X||X||An indicator to link friends, neighbours, relatives, or associates of an individual.|
||X||Attribute assigned to an individual|
|Author||AUTH||X||X||The name of the individual who created or compiled information.|
|Marriage Bann||MARB||X||X||An event of an official public notice given that two people intend to marry.|
|Christening||CHR||X||X||The religious event (not LDS) of baptising and/or naming a child.|
|Baptism||BAPM||X||X||The event of baptism (not LDS), performed in infancy or later.|
|Bar Mitzvah||BARM||X||X||The ceremonial event held when a Jewish boy reaches age 13.|
|Bas Mitzvah||BASM||X||X||The ceremonial event held when a Jewish girl reaches age 13, also known as "Bat Mitzvah."|
|Blessing||BLES||X||X||A religious event of bestowing divine care or intercession. Sometimes given in connection with a naming ceremony.|
|Map||_MAP||X||Anticipation of the 5.5.1 dstandard. Pertains to a representation of measurements usually presented in a graphical form.|
|Map||MAP||X||Pertains to a representation of measurements usually presented in a graphical form.|
|Marriage license||MARL||X||X||An event of obtaining a legal license to marry.|
|Change||CHAN||X||X||Indicates a change, correction, or modification. Typically used in connection with a DATE to specify when a change in information occurred (it is automatically handled by Ancestris)|
|Postal code||POST||X||X||A code used by a postal service to identify an area to facilitate mail handling.|
|Status||STAT||X||X||An assessment of the state or condition of something.|
|Confirmation||CONF||X||X||The religious event (not LDS) of conferring the gift of the Holy Ghost and, among protestants, full church membership.|
|Marriage contract||MARC||X||X||An event of recording a formal agreement of marriage, including the prenuptial agreement in which marriage partners reach agreement about the property rights of one or both, securing property to their
|Marriage settlement||MARS||X||X||An event of creating an agreement between two people contemplating marriage, at which time they agree to release or modify property rights that would otherwise arise from the marriage.|
|Cremation||CREM||X||X||Disposal of the remains of a person's body by fire.|
|Daboville||_DABOVILLE||X||X||Special. It is not defined in the Gedcom format. It is used in Ancestris to generate the Daboville numbering for a descending genealogy.|
|Date||DATE||X||X||The time of an event in a calendar format.|
|Death||DEAT||X||X||The event when mortal life terminates.|
|Graduation||GRAD||X||X||An event of awarding educational diplomas or degrees to individuals.|
|Divorce||DIV||X||X||An event of dissolving a marriage through civil action.|
|Data||DATA||X||X||Pertaining to stored automated information.|
|_EMAI||X||Anticipation of the 5.5.1 standard. An electronic mail address.|
|EMAI||X||Gedcom 5.5.1 only. An electronic mail address.|
||X||Electronic facsimile transmission|
|Child||CHIL||X||X||The natural, adopted, or sealed (LDS) child of a father and a mother.|
|Multimedia element||OBJE||X||X||Pertaining to a grouping of attributes used in describing something. Usually referring to the data required to represent a multimedia object, such an audio recording, a photograph of a person, or an image of a document.|
|Emigration||EMIG||X||X||An event of leaving one's homeland with the intent of residing elsewhere.|
|Wife||WIFE||X||X||An individual in the role as a mother and/or married woman.|
|State||STAE||X||X||A geographical division of a larger jurisdictional area, such as a State within the United States of
|Event||EVEN||X||X||Pertaining to a noteworthy happening related to an individual, a group, or an organization. An EVENt structure is usually qualified or classified by a subordinate use of the TYPE tag.|
|Family||FAM||X||X||Identifies a legal, common law, or other customary relationship of man and woman and their children, if any, or a family created by virtue of the birth of a child to its biological father and mother.|
|Family where person is a child||FAMC||X||X||Identifies the family in which an individual appears as a child.|
|Family where person is a spouse||FAMS||X||X||Identifies the family in which an individual appears as a spouse.|
|Engagement||ENGA||X||X||An event of recording or announcing an agreement between two people to become married.|
|File||FILE||X||X||An information storage place that is ordered and arranged for preservation and reference.|
|Format||FORM||X||X||An assigned name given to a consistent format in which information can be conveyed.|
|Submitter||SUBM||X||X||An individual or organization who contributes genealogical data to a file or transfers it to someone else.|
|Immigration||IMMI||X||X||An event of entering into a new locality with the intent of residing there.|
|Burial||BURI||X||X||The event of the proper disposing of the mortal remains of a deceased person.|
|Ancestor interest||ANCI||X||X||Indicates an interest in additional research for ancestors of this individual.|
|Descendants interest||DESI||X||X||Indicates an interest in research to identify additional descendants of this individual.|
|Language||LANG||X||X||The name of the language used in a communication or transmission of information.|
Anticipation of the 5.5.1 standard. A value indicating a coordinate position on a line, plane, or space.
|Latitude||LATI||X||A value indicating a coordinate position on a line, plane, or space.|
|Place||PLAC||X||X||A jurisdictional name to identify the place or location of an event.|
|Repository||REPO||X||X||An institution or person that has the specified item as part of their collection(s).|
|Longitude||_LONG||X||Anticipation of the 5.5.1 standard. A value indicating a coordinate position on a line, plane, or space.|
|Longitude||LONG||X||A value indicating a coordinate position on a line, plane, or space.|
|Husband||HUSB||X||X||An individual in the family role of a married man or father.|
|Marriage||MARR||X||X||A legal, common-law, or customary event of creating a family unit of a man and a woman as husband and wife.|
|Birth||BIRT||X||X||The event of entering into life.|
|Nationality||NATI||X||X||The national heritage of an individual.|
|Naturalisation||NATU||X||X||The event of obtaining citizenship.|
|Education||EDUC||X||X||Indicator of a level of education attained.|
|Name||NAME||X||X||A word or combination of words used to help identify an individual, title, or other item. More than one NAME line should be used for people who were known by multiple names.|
|Surname||SURN||X||X||A family name passed on or used by members of a family.|
|Number of children||NCHI||X||X||The number of children that this person is known to be the parent of (all marriages) when subordinate to an individual, or that belong to this family when subordinate to a FAM_RECORD.|
|Number of marriages||NMR||X||X||The number of times this person has participated in a family as a spouse or parent.|
|Note||NOTE||X||X||Additional information provided by the submitter for understanding the enclosing data.|
|Identification number||IDNO||X||X||A number assigned to identify a person within some significant external system.|
|Social security number||SSN||X||X||A number assigned by the United States Social Security Administration. Used for tax identification purposes.|
|Binary object||BLOB||X||Set of data entered into a multimedia system that processes binary data to represent images, sound, video.|
|Ordination||ORDN||X||X||A religious event of receiving authority to act in religious matters.|
|Page||PAGE||X||X||A number or description to identify where information can be found in a referenced work.|
|Country||CTRY||X||X||The name or code of the country.|
|Pedigree||PEDI||X||X||Information pertaining to an individual to parent lineage chart.|
|Name prefix||NPFX||X||X||Text which appears on a name line before the given and surname parts of a name. i.e. (Lt. Cmndr.) Joseph /Allen/ jr.
In this example Lt. Cmndr. is considered as the name prefix portion.
|Surname prefix||SPFX||X||X||A name piece used as a non-indexing pre-part of a surname.|
|Given name||GIVN||X||X||A given or earned name used for official identification of a person.|
|First communion||FCOM||X||X||A religious rite, the first act of sharing in the Lord's supper as part of church worship..|
|Private||_PRIV||X||X||Special. It is not defined in the Gedcom format. It is used in Ancestris to mark individuals or events defined as private (private data in preferences tools).|
|Occupation||OCCU||X||X||The type of work or profession of an individual.|
|Publication||PUBL||X||X||Refers to when and/or where a work was published or created.|
|Quality||QUAY||X||X||An assessment of the certainty of the evidence to support the conclusion drawn from evidence.|
|Cause||CAUS||X||X||A description of the cause of the associated event or fact, such as the cause of death.|
|Census||CENS||X||X||The event of the periodic count of the population for a designated locality, such as a national or state Census.|
|Religion||RELI||X||X||A religious denomination to which a person is affiliated or for which a record applies.|
|Divorced filed||DIVF||X||X||An event of filing for a divorce by a spouse.|
|Retirement||RETI||X||X||An event of exiting an occupational relationship with an employer after a qualifying time period.|
|Reference||REFN||X||X||A description or number used to identify an item for filing, storage, or other reference purposes.|
|Relation||RELA||X||X||A relationship value between the indicated contexts.|
|Residence||RESI||X||X||An address or place of residence that a family or individual resided.|
|Role||ROLE||X||X||A name given to a role played by an individual in connection with an event.|
|Sex||SEX||X||X||Indicates the sex of an individual--male or female or unknown.|
|X||X||Special. It is not defined in the Gedcom format. It is used in Ancestris to generate the Sosa or Sosa d'Aboville numbering for a person's ancestors and descendants.|
|Source||SOUR||X||X||The initial or original material from which information was obtained.|
|Name suffix||NSFX||X||X||Text which appears on a name line after or behind the given and surname parts of a name. i.e. Lt. Cmndr. Joseph /Allen/ (jr.)
In this example jr. is considered as the name suffix portion.
|Nickname||NICK||X||X||A descriptive or familiar that is used instead of, or in addition to, one's proper name.|
|Phone||PHON||X||X||A unique number assigned to access a specific telephone.|
|Temple||TEMP||X||X||The name or code that represents the name of an LDS Church Temple.|
|Will||WILL||X||X||A legal document treated as an event, by which a person disposes of his or her estate, to take effect after death. The event date is the date the will was signed while the person was alive.|
|Text||TEXT||X||X||The exact wording found in an original source document.|
|Title||TITL||X||X||A description of a specific writing or other work, such as the title of a book when used in a source context, or a formal designation used by an individual in connection with positions of royalty or other social status, such as Grand Duke.|
|Type||TYPE||X||X||A further qualification to the meaning of the associated superior tag. The value does not have any computer processing reliability. It is more in the form of a short one or two word note that should be displayed any time the associated data is displayed.|
|Probation||PROB||X||X||An event of judicial determination of the validity of a will. May indicate several related court activities over several dates.|
|City||CITY||X||X||A lower level jurisdictional unit. Normally an incorporated municipal unit.|
|Internet web site||_WWW||X||Anticipation of the 5.5.1 standard. World Wide Web home page.|
|Internet web site||WWW||X||World Wide Web home page.|
||X||X||Calculated field indicating whether the media file is a file stored on disk (value 1) or an internet link (value 0). This field is not stored in Gedcom file and is read only.|
||X||X||Calculated field indicating whether the media file exists (value 1) or not (value 0). This field is not stored in Gedcom file and is read only.|
Other predefined tags
They are in the header of the file, except for HEAD and TRLR. They can be visible when opening your Gedcom file in a simple text editor.
While some events are necessarily unique (e.g. birth, death, burial), others may occur several times during a lifetime (e.g. marriage, occupation, residence, divorce).
The various types of events
Whether associated to an individual or a family, there are many different events.
A large number of events are predefined in the Gedcom standard and in Ancestris.
When a type of event has not been predefined, it is possible to choose the event "EVEN" which allows you to specify your own.
Predefined events for individuals
- Adult baptism
- Baptism (give a name) (CHR tag)
- Baptism (sacrament) (BAPM tag)
- Bar mitzvah
- Bas mitzvah
- Birth (BIRT tag)
- Burial (BURI tag)
- Death (DEAT tag)
- Educational level
- First Communion
- Identity number
- Number of children
- Number of marriages
- Occupation (OCCU tag)
- Religion (RELI tag)
- Residence (RESI tag)
- Social Security number
Predefined events for families
- Certificates or authorizations
- Divorce filed
- Marriage (MARR tag)
- Marriage banns (MARB tag)
- Marriage contract (MARC tag)
- Prenuptial marriage contract
An event is generally dated and localized. It can have other properties.
Here is a sample of them.
- Date (tag DATE): date the event took place
- Place (tag PLAC): location where the event took place
- Agency (tag AGNC): the institution or individual validating the event
- Cause (tag CAUS): the cause of the event, such as the cause of death.
- Type (tag TYPE): a short description of the type of event
- Sources (tag SOUR): links to source documents
- Notes (tag NOTE): notes or comments about the event
- Multimedia element (tag OBJE): links to multimedia illustrating the event
The date makes it possible to locate in time any genealogical event: birth, death, marriage, diploma, residence, etc.
In Ancestris, the date can be entered and displayed in different ways because it is set in a given calendar and can be more or less precise.
In Ancestris, date are entered using a specific widget, which is made up of two buttons, one for precision, the other one to specify the calendar, and the three components of a date (month, day and year). Examples :
Relative precision button
The Relative precision button unfolds a mini menu allowing you to indicate whether the date is precise or not, and in that second case, the range.
- Precise Date (default choice): this is a standard date, made up of the month, the day and the year
- Period from/to : this is to express the period of time during which the event has lasted, of was valid, such as a residency in a location.
- Period from : same as above except that there is no end period, the event is still valid today.
- Period To : same as above except that there is no start date. The event was true until the end date.
- Range between/and : this is to express that a short-timed event has taken place somewhere between the dates indicated. For instance, a birth that has happened in the first half of January 1874 could be indicated as
BET 1 JAN 1874 AND 16 JAN 1874. Please note it could also be written
JAN 1874if it were just somewhere in Januray 1874.
- Range before : same as above except that only the maximum end date is known (the minimum start date is not known).
- Range after : same as above except that only the minimum start date is known (the maximum end date is not known).
- About : It means the date is not exact.
- Calculated : Date is calculated mathematically, for example, from an event date and age.
- Estimated : Date is estimated based on an algorithm using some other event date
- Interpreted : Date is interpreted from knowledge about the associated date phrase specified in the field. This date phrase can be any statement offered as a date when the year is not recognizable to a date parser, but which gives
information about when an event occurred.
The Calendar type button opens a mini-menu allowing you to select one of the four calendars available to express the date. Here is an extract from Wikipedia.
- Gregorian : the Gregorian calendar is the calendar used in most of the world. It is named after Pope Gregory XIII, who introduced it in October 1582. The Gregorian calendar is the default choice in Ancestris.
To align the calendar in use in England and in North America to that on the European continent, the Gregorian calendar was adopted, and the calendar was advanced by 11 days: Wednesday 2 September 1752 was followed by Thursday 14 September 1752. The year 1752 was a leap year so that it consisted of 355 days (366 days less 11 omitted).
- Julian : The Julian calendar, proposed by Julius Caesar in 708 Ab urbe condita (AUC, 'from the founding of the City') (46 BC), was a reform of the Roman calendar. It took effect on 1 January 709 AUC (45 BC), by edict. The Julian calendar was the predominant calendar in the Roman world, most of Europe, and in European settlements in the Americas and elsewhere, until it was gradually replaced by the Gregorian calendar, promulgated in 1582 by Pope Gregory XIII. The Julian calendar is still used in parts of the Eastern Orthodox Church and in parts of Oriental Orthodoxy as well as by the Berbers.
- Hebrew : the Hebrew calendar also called Jewish calendar is a lunisolar calendar used today predominantly for Jewish religious observances.
- Republican : the French Republican calendar also called French Revolutionary calendar, was a calendar created and implemented during the French revolution, and used by the French government for about 12 years from late 1793 to 1805, and for 18 days by the Paris Commune in 1871
When a date is currently entered, any change to the calendar type immediately converts that date to the newly selected calendar.
Please note the republican calendar only accepts conversion for dates between September 22, 1792 and December 31, 1805 as these are the main period during which this calendar was used.
In addition, following the name of the calendar, each line of the mini-menu displays the date currently entered, converted into this calendar, with the same exceptions as mentioned above concerning the line of the republican calendar.
Components of a date
The three constituents of a date - month, day and year - line up horizontally, always in the same order.
- The day is the number of the day in the month
- The month is either the number of the month in the year of the month name
- The year is a number on 4 digits.
- When the Precision button is a period or a range, the three components are obviously supplied twice.
The different dates entered in Gedcom files are likely to be displayed in various reports, windows, and views.
The choice of how dates should be displayed is available in the panel Preferences / Data / General data.
Whatever format is adopted, the order of the three constituents of the date is always day month year in the Gedcom file.
In the Preferences, the Dates drop-down menu shows the following four display formats.
GEDCOM Format - 25 JAN 1970
The Gedcom format is the format used in the Gedcom file: the month is written in capitals, using the first three letters of the month in English.
Short Format - 25 Jan 1970
The Short format displays the month in lowercase starting with a capital letter, written using the first three or four letters of the month in English.
Long Format - 25 January 1970
The Long format also displays the full month word in lowercase with a capital letter.
Number Format - 01/25/1970
The Numbers format displays month, day and year as numbers separated by a slashes (/).
A place is a property indicating a physical location associated with an event, and generally provided with a postal address and capable of receiving geographic coordinates (latitude and longitude).
In the Gedcom standard, a place is defined by the PLAC tag.
The value of a place is presented as address elements separated by commas, such as a postal address.
Example (tag and value):
PLAC Hyde Park,02136,Boston,Suffolk,Massachusetts,New England,USA
These elements of the place are called jurisdictions. A jurisdiction, also called a place criteria, is therefore a constitutive element of a place: the city, the postal code, the region, the country, etc.
In the example above, the jurisdictions are:
neighborhood, postal code, city, county, state, region, country.
In the Gedcom standard, the different jurisdictions of a place are organized from left to right, separated by commas, and in increasing order of administrative importance.
The following example, which indicates the jurisdictions in random order, would not be compliant with the Gedcom standard.
PLAC USA,Suffolk,Massachusetts,02136,New England,Hyde Park,Boston
The Gedcom standard allows you to define your own jurisdictions. We can indeed define the parish or neighbourhood level for example, or have two codes within the city: the ZIP or Postal code and the Census units.
How to use the comma
In the Gedcom standard, the comma is the separating element making it possible to distinguish the different jurisdictions of a place.
If one of the jurisdictions of a place is unknown, an empty space will be left to materialize this jurisdiction.
For example, in the absence of neighbourhood and ZIP code, the place of Boston mentioned above would take the following form:
PLAC ,,Boston,Suffolk,Massachusetts,New England,USA
The initial two successive commas indicate the locations of the two unspecified jurisdictions (neighbourhood and ZIP code).
For a good understanding when reading a place, it is therefore essential to respect the location of the commas, and obviously not to use a comma within a jurisdiction.
Please note that the Gedcom file does not accept any blanks on either side of these commas.
- For example, the city of New York keeps its white space between New and York, but no other space character can be added before of after the name.
- To facilitate reading, the various views of Ancestris (in particular the editors) can display spaces after the commas. These spaces are not saved in the Gedcom file.
All places of the same genealogy must be described according to the same jurisdictions and in the same order.
This is the place format of the Gedcom file.
This format is indicated inside the Gedcom file, for all places in the genealogy, in the header of the Gedcom file.
These are the following lines of the header (HEAD) of the Gedcom file that will indicate this correspondence
2 FORM neighbourhood, postal code, city, county, state, region, country
This format is optional in the header but in terms of consistency and data quality we strongly recommend using it.
For a genealogy covering several countries, you therefore need a generic format that is extensive enough to allow the places of all the countries considered to be referenced under the same format.
Changing place formatting
The Modification of place criteria window allows to add or remove a type of jurisdiction in the format of the location, and also to modify the order of the different types of jurisdictions, for all locations and all the entities of the genealogy file. This window is accessible from the File / Properties menu.
To enter a location, you must rank the different jurisdictions in ascending order of importance, separating each level with a comma.
If a jurisdiction is not entered, the comma must be kept.
Entering a place
If in the Preferences you have chosen the presentation Split jurisdictions to edit in Gedcom editor, you do not have to worry about the explanations which follow, you will enter the jurisdictions separately, that is to say, level by level .
Otherwise, you must enter your locations globally, that is, as a serie of jurisdictions separated by commas.
For example, if the format is
neighbourhood, postal code, city, county, state, region, country, for an event located at Hyde Park in Boston, ZIP Code 02136, state of Massachusetts, in the USA, you should enter:
- Nothing should follow the country name.
- If a jurisdiction is unknown, a comma is repeated, even if it stands at the beginning of a line.
- If only Boston is known, in the USA, then we would write:
The principle is easy:
- From the smallest to the largest jurisdictions
- All jurisdictions are separated by a comma, even if left empty
Auto-completion of place jurisdictions
While entering a place name, a drop-down menu will open offering you already known places with the same string of characters inside the name. Just click the suggested line and press OK to select.
If you have chosen to display separate jurisdictions in the Preferences, this feature also exists, but line by line.
Change all places in one single change
If you notice that from the beginning, you made a typing error on a place, or if the same place was registered in different ways, you may want to make a change of all the erroneous places in one single change without having to go back in each of them to correct them.
Some pieces of information collated in a genealogy can either be specific to an individual, or shared by several individuals or several families of that genealogy.
A genealogy contains a lot of information, you will necessarily want to be able to reuse most of it.
If you want to reuse information, we strongly recommend that you initially store it in an entity rather than in a property.
This is the case for all Notes, all Sources, all Repositories, and all Multimedia Elements.
These Entities are defined here in the dedicated Entities.
Other information in Ancestris can be reused in a transparent way for you: these are places, occupations, types of events, diplomas, etc., and more generally all the short labels which describe events.
The principle, before creating any information in Ancestris, is to ask yourself whether this information is likely to be used again or not for other individuals.
Creation of shared information
If the information is likely to be reused:
- first create it as a new entity as such
- then link it from the other entity that will use it
In certain cases, the choice of shared information is obvious, such as repositories for instance.
In other cases, this choice is more subtle, such as Sources and Notes.
Entities using shared information
Another benefit of using shared entities is when you want to know all the entities in your genealogy that use a given information. You can know so by selecting the shared entity. The list of entities that use it appears in a list attached to this shared entity.
Conversely, it is a way to know if a shared entity is still being used at all.
Case of repositories
During your genealogical research, you will probably collect several documents originating from the same location.
To store all this information, you will create this location as a single repository, indicating its description, address, contact details, etc.
Then all the extracted documents will be your sources. Each of these sources will indicate the same repository.
This repository can also be a regional archive, a town hall, a website, a cemetery for instance.
Example of three sources from the same repository:
Case of a family certificate
If you discover a family certificate in which are indicated 3 children, and that in addition you write a note explaining your research story, you will have a diagram which could look like this:
The 3 individuals represent the siblings. Their births are sourced from the family certificate, which itself is sourced from a repository.
And your note comes in to support your research or observations about the 3 births.
You will notice in the diagram above that the source relates to the birth events of individuals, and not the individuals directly, which is more precise.
I assumed in the example that your note only spoke about the births of individuals. If it talked about their lives more broadly, you should probably link your note to the individuals rather than just to their birth.
Case of a note
On the other hand, a note which comments on specific circumstances relating only to one single individual in particular should preferably be entered as an individual note and not generate the creation of a dedicated Note entity.
This is the case, for example, for details of a birth (the height and weight of the child, the fact that the person was born at his parents' home, etc.). These details will only ever relate to the birth of the individual considered and it is more efficient to enter this information directly at the birth level as an individual note.
Case of a place
The first time a place is created, it appears in the event where it is used first. Ancestris does not allow you to put it in a Place entity, even if you think you might need to reuse it later. This is because the Gedcom standard did not define places as entities.
This is not a problem, Ancestris manages the repository of places for you and considers that each place can be reused.
However, you must be careful when you create a place: it is up to you to check if it does not already exist, in order to avoid creating a duplicate. A duplicate on a place is not annoying as such, but it becomes so when, for example, you correct one of the two while thinking of correcting them all.
To avoid generating a duplicate when entering a place, Ancestris automatically suggests all the places found in your genealogy that include the text being entered.
Also, thanks to the List of places view, it is possible to merge places that have been entered twice by mistake.
The creation of Notes, Sources, Repositories, and Multimedia Elements is done either via the Context Menu of Ancestris, or via the menu bar, or automatically from the Cygnus editor or manually from the Aries editor.
The creation of places is done by entering a place directly in the editors, or in the Places editor.
To find out the list of entities using a particular Note, Source, Repository or Multimedia Element, all you have to do is select it from the table of entities for example, and view it in the Gedcom Editor.
You will then see all the entities using this information as linked properties.
This source S5 is used by four other entities of the genealogy: the note N2 on the assassination by Ravaillac, the name of the individual I29 Robert Capet, the death of Louis IX, and the name of Marguerite de Provence.
In the case of a Place, the easiest way to find out in which events it is used, is to go to the List of Places and select it. Events are listed by expanding the flap in the list. See the List of Places for more details.
There is an educational B-A-BA on shared information in PDF format. It is written in French.
It corresponds to version 9 of Ancestris but most of it is still relevant.
It tells you in detail how to create and use each of the shared entities presented above.
You can download it here.
In order to be able to navigate your genealogy or in order to transmit this lifelong effort amount of information, it is necessary to remain consistent in the way you write similar types of information.
The Gedcom standard is a strong reference for this and suggests an extensive way to structure and specify your information.
Even staying within the standard, there are sometimes various possibilities to enter locations, notes, sources, events, media, etc. You may therefore want to control the quality of your data to make sure is it consistent.
We have identified several types of controls you can make:
- Gedcom compliance. Example : only one birth is possible for an individual, a tag is undefined, a date cannot be empty, etc.
- Genealogical data consistency : invalid date, persons buried before their death, age difference between spouse too long, person too young to have a child, etc.
- Places non in line with the place format
- Multimedia object not found on disk
Ancestris provides a way to know if the information entered is consistent with the standard, consistent with each other, or aligned with a format.
To identify most of the anomalies listed above, you may go to Menu / Tools / Validate Gedcom compliance and data consistency.
To rectify places and multimedia elements, you have File / Properties.