Suggested GEDCOM updates

Through use and changes in convention here, there are many suggested updates to the GEDCOM 5.5.1 specification and related processing software to better support the capture and maintenance of information. See Genealogy Database Tips for the conventions adopted here that lead to many of these suggestions.

---

Add additional Pedigree Linkage Type of STEP

We need a mechanism to create families of important households without a formal or legal standing. Currently, Pedigree and Family references are based on legal (adoption, biological parent) and religious convention. But this does not properly reflect familial relationships that were important to the individuals involved. Especially for young minors. This allows one to reflect that a minor child was part of a tight-nit household and likely considers the step-parent as their only parent. Often true when the biological parent died early in the child's life and the remaining parent remarries. Or anytime while minor children are still in the house but no formal adoption has taken place. The child may know no other parent. The new parent does not always adopt (or is able to if there was a defacto divorce due to abandonment, for example). This is a quasi state between ADOP and "showing nothing" to reflect important household relationships that were treated as family throughout life.

Note this could also be used when Aunts/Uncles/Grandparents take in a niece/nephew/grandkid. Some of these situations could possibly have led to an ADOP but did not for whatever reason. This tag is simply distinguishing from that legal step not taken to reflect the reality of familial relationships and the child's viewpoint through out life.

Workaround

Use Pedigree type FOSTER and add a note. Or use Pedigree of ADOPTED and add a Status of Challenged along with a note to indicate unknown but treated like.

Allow Association (ASSO) Structure within Event and Attribute tags

Currently ASSOciate is only defined as a level 1 tag within an INDIvidual record. Most tools (rightly) support it as part of EVENT_DETAIL within any Event or Attribute. This indirect association of individuals is more proper than the current restriction of INDIvidual to INDIvidual only. Needed mainly for EVENt records so things like Baptism, Confirmation, Marriage and similar can list the appropriate people.

A glaring need for this method is when trying to define the Wedding Party within a marriage in a family. The Wedding party is associated with the marriage and not one individual. As an individual may have more than one marriage, tying the wedding party to the Individual record can lead to duplication of information (required in each Spouse record), and confusion (multiple Best Man's and Made of Honors as not tied to specific Marriage event).

Workaround

Pull all Association tags out of Events and up to the owning Individual Record or Spousal Records if a Marriage. Add a note to indicate the defining event OR copy the Citation link from the defining event to this Association.

Pre-define ASSO RELAtionships that are common

Need a pre-seeded list of commonly used Relationship's for the ASSO tag. Would be nice to have the major religions (Jewish, Christian/Catholic, Islamic) better covered for their major Events already defined (Baptism, Confirmation, Marriage, etc). This way the tools are pre-seeded to suggest common values to add. And Internationalization can be accomplished by providing the language translation for pre-seeded names.

Workaround

Publish and use a pre-seeded list of text strings. Encourage use in tool before adding a custom text string.

Simplify Source Citations to just a linked Source xref_ID

There are many cases where the same Source Citation is useful in many records (INDI, FAMI) and Events. This because the citation may be associated with a single page document such as a page out of census, a birth certificate, a marriage application, a death certificate, or a death notice. To prevent duplication and errors introduced by editing, you would like to create a single place for the information contained in the Citation and then have the information simply referenced from the multiple places.

Making Source Citation into simple reference links and then pushing (the current) Source Citation information into their own top-level record simply duplicates the Source structure already existing. So likely the elegant solution is to simplify Source Citation's to just links and then allow Source Citations within Source records themselves (see below). This would allow hierarchical Source's that are built up. That is a source reference is a page out of a larger reference. Repositories simply become the final, physical source reference.

Workaround

One can pseudo-handle it now by pushing everything one level: source citations are simplified to just links, Source Records become like Source Citations, and repositories become like Source Records are used today. This works well if you attach media items to the Sources then (and not Source Citations) and include transcriptions of the Media object information in the Source itself. Collections of sources (all pages from a marriage book, census in a county, etc) can then be specified in the current mechanism for a Repository.

Allow Source Citations and Multimedia Links within all primary Records

Need to have Source Citations in the Multimedia (OBJE) and Source (SOUR) records themselves. Any primary record is a declaration of information and needs to be sourced. Adding the citation to Source Records is in conjunction with the earlier suggestion to simplify Citations to just the Source Link.

Note that the Records Header, Submission and Submitter are special records that are like Sources themselves and do not need the Source Citation. Could be added to the Repository record but the need is not as glaring as for others.

With the two suggested changes, Multimedia Links are removed from Source Citations (properly and any need for). This also shows that a Source Citation and a Multimedia Link are allowed in most top-level Records. Should simply allow both anytime one or the other is allowed? That is, add Multimedia Link in the Repository, Note and Multimedia Record. Maybe remove the Multimedia Link from the Submitter for consistency (as well as add a Note Structure there).

Workaround

none

Add date range (start, stop) for all top level objects

Individuals have a specific birth and death to bound their "existence". But Families have a beginning and end as well. Begin is derived as either a marriage or first child, usually. And end often on the death of both parents (as we assume the children are grown and onto creating their own families; or tragedy splits the family up so children go to other caretakers.) Residences (or top-level Place Record) should also have associated date ranges. And even events should allow a date range when the data is unknown but a bound can be calculated (puberty age, marriage or death of parent; for example).

Allowing the date range to be used as part of the database "key" for each Record and Event will help more clearly define information for a specific time. So we either update everything when a country comes or goes (i.e. keep Places as current) or use date ranges on everything so the place at the time of a cluster of events could be defined and stands on its own no matter what happens in the future. Information such as the length of time at an address or that the Place (residence) existed could be captured also.

And in reality, we need the date range for most facts and events. While some events are pretty specific — birth, marriage ceremony, death — others require a range of validity like a residence, contact information, occupation, and such. So pretty much allow everything to be tagged with a date range mechanism to allow the most flexible and processable mechanism to enhance most top-level Records, Attributes/Facts and Events.

As Dates are not allowed in Records now, am not advocating creating them except to capture derived or estimated information. But this could lead to inconsistency. The Multimedia Object Record should likely have a specific Date or Date Range associated with it to specify when it was initially created (photo taken, publication date, etc).

Workaround

none

Add a fifth, defined level to PLAC to reflect the actual place.

The fifth level defines the actual location. Can be the name of an institution such as a Hospital, University, School or Business. Or can simply be a street address for a residence or when nothing else works. Using an institution helps when it changes buildings and street addresses over time. City, County, State, Country is not specific enough to promote PLACe to be the top level record it needs to be (like INDIvidual and FAMIly). Having this fifth level allows for more precise geographical coordinates as well.

Another clear example of a fifth-level PLACe to capture is a cemetery. Especially since the Cemetery tag was dropped. Just like a residence, this becomes a "final resting place" or residence for an individual. This institution, likes others, needs more of a description and having the place designator does that. And like for any multi-family or large unit, there is likely a sixth designator of a specific location within the cemetery as well (section, plot). But we are not advocating going further than five levels.

Workaround

Simply use convention and make sure Header reflects this unconventional use. Some tools may not support.

Make PLAC into a Primary record

Making PLACe a Primary Record can be useful in a number of ways. It allows us going forward to further expand on the location of an occupation and work experience more clearly. Since the start of the Industrial revolution, the capture and understanding of such a place or institution is important. (So much so that maybe, like states do, we should allow "Corporations" and "Businesses" as if "Individuals" as well.) So PLAC is not just a tag with a geographical location like a street address but often more.

Just as city, county and similar boundaries change and vary with time, so would the physical location of a PLAC institution. So a PLAC top-level record could have multiple ADDR tags with time records to indicate its multiple locations.

So change all PLAC tags to PLAC links with xref_ID's like used for Individuals and Families. Possibly move all Address Structures to only be within a PLAC record and use PLAC links where Address is currently allowed. A PLACe Record is defined with the GPS coordinates along with the Address Structure to give an approximate center of the location. Change the RESI tag inside Individuals and Families to be a reference to the PLAC xref_ID along with a date (range) to identify how long they were there. A street address for a home or multi-family residence would be a Primary Record, as would a cemetery. Apartment numbers, plot numbers and the like would be further description elaborating the PLAC citation; similar to a Repository Citation Call number.

Workaround

none; although many tools basically support Places as primary records now.

More formally add a story or bulk description reference

Primary records (INDividuals, FAMIlies, SOURces, REPOsitories and PLACe's) need some glob reference to either a Wiki page, unstructured document or similar to capture all the unstructured but needed info. NOTE is not enough. A wiki mechanism does introducing linking outside the structured GEDCOM reference structure but possibly this is a good thing. The key is to be able to capture, store, present and maintain the fluid development of information about history of people, families and places.

Carrying on the example above, a Cemetery could then have its section and plot maps in addition to history and other information captured in its Place Wiki page.

Workaround

Use a processable note or custom tag to indicate the URL for a Wiki link. A tool could then look for this and process it specially.

Promote Places to top level object

Places really need to be promoted to a top-level object like Individual, Family, etc. Maintain the "tuple" hierarchy and expand to even 6 levels of administrative / political / etc boundary and hierarchy. But key is get them as primary with all the ability to use sources and source references.

Workaround

None. Major change with much detail to be fleshed out.

Add new Object as top level object

OK, overuse of the term. And maybe just rename Media to be this new top-level construct. But key is that all documents, photographs, etc should become Objects. And they need a hierarchy like Location (Places above). Now, Source citations are more like ASSOCiations added to EVENTs. Except, in this case, Source citations in FACTs. Source citations should simply associate or link a refined Object (document) item that is a page from a larger Object. In that page Object should be a transcription, media image, and so on. It is then part of a next level up Object until you get to the primary, highest level. In some sense, the PLACE/Location is a special Object that has refined geographical location on the Earth as part of its definition. Now Objects can be collected and available in a Repository of Objects. That is, a Library, NARA, etc. Currently, Objects are pseudo-items that are part of a Source definition.

Workaround

None. Major change with much detail to be flushed out.