GEDCOM  Details

Table of Contents

Before describing data panels in detail, we need to introduce some terminology and GEDCOM concepts. GEDCOM organizes data into a basic structure called an element. An element can have a value and/or a list of elements. For example, an individual's personal name is an element which consists of a list of elements, each of which has a value that corresponds to a component of the personal name. (the given name, the surname, a title, etc.) For this document, we will refer to a simple element that only has a value (for example the surname element) as a data component. We will use the term element to refer to complex elements that contain a list of components. Components are either data components or other elements. Sometimes, an element may contain an array of related elements. For example an individual may have a set of personal names (aliases). We will describe this set of related elements as belonging to a container, for example an "alias" container contains a list of personal names elements.

As mentioned earlier, GEDCOM data is organized in an hierarchical manner. So to further facilitate our understanding, we will introduce the terms of a parent element and its child elements to describe these relationships. This is just another way of expressing that, like the idea that a folder can contain a set of folders or pieces of paper, a parent element contains a set of child elements, each child element is composed of either an element or a data component.

Now for a bit of a curve.. Above, we defined an element as something that either has a value (i.e it is a data component) or it holds a list of other elements. This is not the complete picture however. There are actually two different types of "values" an element can contain. One type is the aforementioned "direct" value type whereby the element holds the actual data associated with it. In order to facilitate the reuse of certain types of data, GEDCOM introduces the concept of a record element. A record element is a stand-alone element, in other words it is an element without a true parent element. (more on this later) In order to work with record elements, an element can also have a "reference" value type. We will call these types of elements, reference elements. In this case a reference element's value is not simple data, but it is a reference (pointer) to a GEDCOM record element.

To help understand this rather complicated picture, lets use an example. Suppose Aunt Bessie and Aunt Julie were born in the same house and we wanted to attach a note to each of their birth event information describing the house they were born in. Instead of having to enter that note twice, once into both Aunt Bessie's data and once into Aunt Julie's data, as a data component for each, GEDCOM allows that note to be placed into the data base as a note record element. Then a reference element is placed into the birth element's list for both Aunt Bessie and Aunt Julie. It is important to understand that a reference element contains a pointer to the note record. Many different elements within a single GEDCOM data base may contain reference elements which point to the same record element. Thus, in our example if the note record element describing the house Aunt Bessie and Aunt Julie were born in, was changed or edited, both of their birth event descriptions would see and reflect that note change simultaneously! This feature saves the user from having to re-enter redundant data sometimes.

Although the idea of being able to reuse certain types of data for different purposes is a powerful concept, it is also a complicated idea to grasp and many vendors of genealogy tools will simply try to hide this feature from their users in some fashion. One common approach taken by vendors is to simply not use one of these element value types, when they create a GEDCOM database. One vendor may choose to simply always use reference and record element combinations, whenever possible, and always place all data in a record element without the user even being aware that this is what is happening. Another vender may do exactly the opposite and never use reference and record elements and require/place the burden on the user to enter redundant data whenever it is needed. Since JPriseMerge can work with/merge many different vendor's GEDCOM databases, we cannot completely hide this capability, like many of them do, and must completely expose the database structures to our users. This then is one aspect of how we allow our users to have complete control over doing merges. Therefore it will require some understanding of how these concepts work and we apologize if this is a bit overwhelming at first encounter.

 

Click here to provide feedback to JPrise Inc.

Copyright © 2004 JPrise Inc. All rights reserved