GEDCOM records can be identified in multiple ways.
The GEDCOM grammar provides exactly one way to identify a record:
by their record identifier (RID).
The LINEAGE_LINKED form defines multiple subrecords for identifying records and,
as if that was enough yet, systems may use GEDCOM extensions;
many systems support the _UID record.
The LINEAGE-:INKED 5.5.5 specification simplifies things with three record types for three use cases;REFNfor use-defined identifiers,IDNOfor third-party identifiers, andRINfor uniquely identifying records in inter-system communication,
REFNIDNO RIN The GEDCOM 5.5.1 LINEAGE-LINKED form has six different record types for identifiers..
The LINEAGE-:INKED 5.5.5 specification simplifies things
with three record types for three use cases;
REFN for use-defined identifiers,
IDNO for third-party identifiers,
and RIN for uniquely identifying records in inter-system communication,
That may sound good, bu there is a problem; its RIN definition
has not improved on the GEDCOM 5.5 and 5.5.1 specification.
The LINEAGE-:INKED form defines a CALN (call number) record as well,
but that is a subrecord for identifying items in a repository,
while this article is about identifiers for GEDCOM records.
_UID This widely supported GEDCOM extension is discussed in The _UID tag.
That article includes is a long but not exhaustive list of genealogy software
that supports this common extension.
While Ancestry Family Tree Maker supports _UID,
Ancestry.com uses UID (no underscore) instead.
The above quick overview is not complete. There surely are additional system-specific record identifiers, but that is not all. As already mentioned, the LINEAGE-LINKED 5.5.1 form has three more record types for identifiers.
Extensions should be documented in their own, separate specification.
SSNAFNRFNThe SSN record is for American Social Security Numbers ,
the AFN record is a system-specific identifier for Ancestral File.
Both are design mistakes corrected in GEDCOM 5.5.5.
The SSN record is a design mistake for two reasons.
First of all, there are many more such numbers
(e.g. passport numbers), and many more countries.
so this design direction leads to an unmanageable explosion of record types.
The second and arguably more important reasons is that
it merely duplicates functionality already provided
by the IDNO record,
so it violates the design principle that
there should be only one way of recording data in GEDCOM.
Obsolence should be expected for every product, and that makes inclusion of product-specific identifiers in the specification a bad idea already.
Practically speaking, the AFN record is obsolete
because Ancestral File is obsolete.
Obsolence should be expected for every product,
and that makes inclusion of product-specific identifiers in the specification a bad idea already,
The AFN record is a design mistakes for yet more reasons.
A fundamental issue with the AFN record is that
it isn’t a proper LINEAGE-LINKED record at all,
but actually a company-specific and even product-specific extension,
mispresented as a regular record.
Mispresenting company- or product-specific extension as part of
the specification itself is not only disingenuous,
the inclusion of extensions in the spec is a bad idea,
as this too tends to expand the specification to unmanageable proportions.
Extensions should be documented in their own, separate specification.
Because it is an extension, the AFN record should really
have been named the _AFN record; it should start with
an underscore to indicate that it is an extension.
Just like the SSN record, the AFN record
duplicates functionality already provided by the IDNO record.
While there is no practical reason to bother with Ancestral File identifiers at all,
GEDCOM still allows you to record them using the IDNO record.
There are two differentRFNrecord types in GEDCOM 5.5.1, theSUBN.RFNrecord and theINDI.RFNrecord.
Within GEDCOM, the meaning of GEDCOM tags depends on context,
specifically what record it appears within.
For example, the HEAD.ZOUR contains a so-called system identifier,
while the top-level SOUR documents a source.
There are two different RFN record types in GEDCOM 5.5.1,
the SUBN.RFN record and the INDI.RFN record.
The SUBN (submission) record should not be confused
with the SUBM (submitter) record.
The SUBM record tells you who created a GEDCOM file,
which is of some general use.
The SUBN record is specific to Ancestral File;
the comments regarding the AFN record
also apply to SUBN record and its SUBN.RFN subrecord.
The SUBN.RFN record was meant to identify an Ancestral File submitter.
The INDI.RFN record defined in GEDCOM 5.5.1 is part of
an intended future feature that remained incompletely defined.
The practical upshot is that the INDI.RFN record can
legally be included in a GEDCOM file,
but cannot actually be used,
as it requires so-called registered resource identifiers, which were never defined.
Technically, the INDI.RFN record is not obsolete, because it was never current.
See GEDCOM Identifiers: Pointer Syntax for a detailed discussion of this.
System-specific identifiers do not need system-specific records or tags.
System-specific identifiers do not need system-specific records or tags.
System-specific identifiers can and should use the IDNO record.
The WikiTree GEDCOM article shows a partial WikiTree GEDCOM,
in which WikiTree uses the REFN record instead of the IDNO record,
and the GEDCOM RIN article observed that
Family Tree Maker has a misfeature to generate unique REFN records.
The REFN record is for users, not for systems.
No system should be generating REFN records,.
The REFN record is for users, not for systems.
Systems should always use IDNO for all system-specific identifiers.
According to the GEDCOM 5.5.1 specification,
IDNO is a number assigned to identify
a person within some significant external system
and its NATIONAL_ID_NUMBER is a nationally controlled number
.
That definition gives SSN as an example of such a number,
despite GEDCOM 5.5.1 still having a separate SSN record for that.
GEDCOM 5.5.5 generalises the IDNO definition.
It continues to allows the existing usage, including its use for SSN,
and gets rid of the unmotivated nationally controlled
. restriction.
In GEDCOM 5.5.5, theID)NUMBER value
can be any third-party number assigned to an individual
The GEDCOM 5.5.5 specification is less than crystal-clear
about what is meant by third-party
in the context of a GEDCOM file.
When a system exports identifiers it generated,
those identifiers are first-party identifiers,
yet third-party identifiers to another system importing that GEDCOM file.
To a user all system-generated identifiers are third-party identifiers.
Systems should use IDNO for system-specific unique identifiers,
not use RIN or REFN instead.
TheREFN record is for users,
and the RIN & _UID record is specifically
for inter-system identification of top-level records
- and even if it was a proper choice, it would still be an impractical one.
The significant advantage of the IDNO record
over company- and product-specific extensions is
that the IDNO record is widely supported,
by practically all genealogy software
The IDNO record has been part of the LINEAGE-LINKED form for decades.
While company- and product-specific extensions tend to get lost on import
to a third-party product, identifiers recorded in IDNO records
should not be lost, but survive import & export through multiple products.
The GEDCOM 5.5.5 standard prescribes that
vendors take advantage of that IDNO advantage.
The specification explicitly states that it is illegal for an extension
to duplicate already existing functionality.
The specification allows extensions,
but does no longer allow vendors to use its own badly supported extensions
instead widely supported standard records,
According to the GEDCOM 5.5.5 specification,
systems should be using the RIN record,
but as discussed in GEDCOM RIN,
the RIN record definition is both
incomplete and somewhat self-contradictory.
Few vendors have even attempted to support it in their products
and the few that tried ended up violating the specification they intended to support.
In contrast, the _UID record is widely supported.
The key differences that made the _UID record successful
is that systems can simply import and export existing _UID values,
and may generate a value when there is none yet,
using an explicitly defined public algorithm, without fear of value collision.
The practical truth is that the _UID system is working across many systems,
and vendors would be mad to stop using it.
The _UID extension is so successful
that it should be codified in GEDCOM as the UID record.
Meanwhile, the fact that the _UID record has the same intended
purpose as the RIN record does not make it illegal
to use the _UID record in GEDCOM 5.5.5 or later.
It would be illegal if it duplicated existing functionality,
but the simple truth, put politely,
is that the _UID record does
what the RIN record is supposed to do.
It must be noted that big systems such as
Ancestry Family Trees, MyHeritage, Geni.com and WikiTree,
are system where. simply put, all records are kept in a single large database.
This is not about the user experiencing either a private or a shared database,
but about all records for all users being stored in single large database,
in which all those records having unique record identifiers (RIDs).
If a system like that generates IDNO records
with unchanging values that are unique within that system,
then those IDNO records can serve
the intended purpose of the RIN record,
as the IDNO records carry both that unique value
and a value identifying the system.
The system still needs to support _UID records
for compatibility with other systems.
Every system should at least import and exports _UID records,
to help ensure that they do not get lost on import/export,
in which case some other system might generate a new _UID
with a different value.
System should use three different record types for three different use cases;REFNfor use-defined identifiers,IDNOfor third-party identifiers, and_UIDfor uniquely identifying records in inter-system communication,
Systems do not need any extensions,
but can use the standard IDNO record for all their system-specific identifiers.
The IDNO record is superior to system-specific extensions,
as it will survive import & export through many systems.
Systems should import, export and display REFN records,
but not generate REFN records.
The RIN is too ill-defined to be fit for purpose,
but the widely supported _UID record does
what the RIN record is supposed to do.
All systems should at least import _UID record and export them again,
even if they do not use or generate _UID codes.
System should use three differnt record types for three different use cases;
REFN for use-defined identifiers,
IDNO for third-party identifiers,
and _UID for uniquely identifying records in inter-system communication,
Copyright © Tamura Jones. All Rights reserved.