title: "Extended Legacy Format (ELF)" subtitle: Data Model date: 13 August 2018 numbersections: true ...
{.ednote ...} This is an exploratory draft of the genealogical data model for FHISO's proposed suite of Extended Legacy Format (ELF) standards. This document is not endorsed by the FHISO membership, and may be updated, replaced or obsoleted by other documents at any time.
Comments on this draft should be directed to the [email protected] mailing list. {/}
FHISO's Extended Legacy Format (or ELF) is a hierarchical serialisation format and genealogical data model that is fully compatible with GEDCOM, but with the addition of a structured extensibility mechanism. It also clarifies some ambiguities that were present in GEDCOM and documents best current practice.
The GEDCOM file format developed by The Church of Jesus Christ of Latter-day Saints is the de facto standard for the exchange of genealogical data between applications and data providers. Its most recent version is GEDCOM 5.5.1 which was produced in 1999, but despite many technological advances since then, GEDCOM has remained unchanged.
{.note} Strictly, [GEDCOM 5.5] was the last version to be publicly released back in 1996. However a draft dated 2 October 1999 of a proposed [GEDCOM 5.5.1] was made public; it is generally considered to have the status of a standard and has been widely implemented as such.
FHISO are undertaking a program of work to produce a modernised yet backward-compatible reformulation of GEDCOM under the name ELF, the new name having been chosen to avoid confusion with any other updates or extensions to GEDCOM, or any future use of the term by The Church of Jesus Christ of Latter-day Saints. This document is one of two that form the initial suite of ELF standards, known collectively as ELF 1.0.0:
-
ELF: Serialisation Format. This standard defines a general-purpose serialisation format based on the GEDCOM data format which encodes a dataset as a hierarchical series of lines, and provides low-level facilities such as escaping and extensibility mechanisms.
-
ELF: Date, Age and Time Microformats. This standard defines microformats for representing dates, ages and times in arbitrary calendars, together with how they are applied to the Gregorian, Julian, French Republican and Hebrew calendars. These formats are largely identical to those used in GEDCOM, but the framework should serve as a basis for future work on calendars.
-
ELF: Data Model. This standard defines a data model based on the lineage-linked GEDCOM form, reformulated in terms of the serialisation model described in this document. It is not a major update to the GEDCOM data model, but rather a basis for future extension.
This document describes version "1.0.0" of the ELF data model.
The version string uses the semantic versioning tradition outlined in https://semver.org:
three integers, separated by periods, where an application expecting on version
can process any other with the same first integer.
The IRI for this any version of the ELF data model can be created
by prepending https://fhiso.org/TR/elf-data-model/v to the version;
for this document's version, that IRI is
https://fhiso.org/TR/elf-data-model/v1.0.0
{.ednote} This IRI was generated just as a placeholder; the correct IRI is not yet determined.
Where this standard gives a specific technical meaning to a word or phrase, that word or phrase is formatted in bold text in its initial definition, and in italics when used elsewhere. The key words must, must not, required, shall, shall not, should, should not, recommended, not recommended, may and optional in this standard are to be interpreted as described in [RFC 2119].
An application is conformant with this standard if and only if it obeys all the requirements and prohibitions contained in this document, as indicated by use of the words must, must not, required, shall and shall not, and the relevant parts of its normative references. Standards referencing this standard must not loosen any of the requirements and prohibitions made by this standard, nor place additional requirements or prohibitions on the constructs defined herein.
{.note} Derived standards are not allowed to add or remove requirements or prohibitions on the facilities defined herein so as to preserve interoperability between applications. Data generated by one conformant application must always be acceptable to another conformant application, regardless of what additional standards each may conform to.
If a conformant application encounters data that does not conform to this standard, it may issue a warning or error message, and may terminate processing of the document or data fragment.
This standard depends on FHISO's Basic Concepts for Genealogical Standards standard. To be conformant with this standard, an application must also be conformant with [Basic Concepts]. Concepts defined in that standard are used here without further definition.
{.note} In particular, precise meaning of string, character, namespace name, prefix notation, prefix, whitespace and term are given in [Basic Concepts].
Indented text in grey or coloured boxes does not form a normative part of this standard, and is labelled as either an example or a note.
{.ednote} Editorial notes, such as this, are used to record outstanding issues, or points where there is not yet consensus; they will be resolved and removed for the final standard. Examples and notes will be retained in the standard.
The grammar given here uses the form of EBNF notation defined in §6 of [XML], except that no significance is attached to the capitalisation of grammar symbols. Conforming applications must not generate data not conforming to the syntax given here, but non-conforming syntax may be accepted and processed by a conforming application in an implementation-defined manner.
This standard uses the prefix notation, as defined in §4.3 of [Basic Concepts], when discussing specific terms. The following prefix binding is assumed in this standard:
elf https://terms.fhiso.org/elf/
{.note} The particular prefix assigned above have no relevance outside this standard document as prefix notation is not used in the formal data model defined by this standard. This notation is simply a notational convenience to make the standard easier to read.
A line string is a string that shall be whitespace-normalised before being processed.
{.note} In a line string, the production S defined in [Basic
Concepts] collapses to a single space character (U+0020).
A line break is defined as either a carriage return, a line feed, or
a carriage return followed by a line feed. It matches the production
LB:
LB ::= #xD #xA? | #xA
A padded linebreak is defined as a linebreak preceded by zero or more space characters or tabs. It matches the production
PLB:
PLB ::= (#x20 | #x9)* LB
Linebreak normalisation is the process of replacing each padded linebreak with a single linebreak, where all are replaced by the same linebreak variant, and removing any U+0020 (space) and U+0009 (tab) from the end of the string.
{.ednote} GEDCOM 5.5.1 is inconsistent on its definition of line break handling. Pages 10 and 37 state that initial spaces are preserved and trailing are removed (on most systems), which is given in the above rules; however page 85 indicates states that both initial an trailing spaces are removed, albeit obliquely.
A block string is a string that SHALL be linebreak-normalised before being processed.
{.note} linebreak normalisation is provide as a data model parallel
to how lines are encoded with CONT tags in [ELF-Serialisation].
It is possible that a future version of this standard might change
this presentation, perhaps redefining block string as a list of
strings, each representing a single conceptual "line".
The structure type identifiers used in this specification are terms.
The term names of the structure type identifiers defined in this
standard all begin https://terms.fhiso.org/elf/. It is recommended
that any extension structure type identifiers also use the https IRI
scheme defined in §2.7.1 of [RFC 7230],
and an authority component consisting of just a domain name (or
subdomain) under the control of the party defining the extension
structure type identifier.
Several microformats are used in payloads of various structures below.
A list of line-strings serialized with commas in between. There is no mechanism provided for including commas or leading or trailing spaces within an element of a comma-separated list.
A full name, presented in the order usually spoken and with the capitalization typical of the culture of the named individual.
The text should not include commas or digits.
{.ednote} GEDCOM 5.5.1 (page 56) requires that names not include "commas, numbers, or special characters not considered diacritics". The above is less strict; should we instead require it, or remove it altogether?
It should include exactly two U+002F SOLIDUS / characters, one on each side of the family name or surname if present, or adjacent to one another if no family name or surname name is known.
Portions of the name may be elided and replaced by three U+002E FULL STOP ....
This should only be done if part of a name is known to exist but its content is not known.
{.ednote} TO DO: fill this section using the "either GEDCOM or IANA" concept outlined in languages.tsv.
Every Extended Legacy Format (ELF) dataset is two sets of structures.
The first, described as the elf:Document, is a set of [elf:Record]s which, with their substructures, provide the principle data of the dataset.
The other, described as the elf:Metadata, is a set of additional structures which, with the substructures, provide metadata about the dataset as a whole.
{.note} This entire section is non-normative
Sometimes a researcher encounters a state where the they are unsure which of a set of alternatives is true. GEDCOM did not provide guidance on how this state should be recorded, and hence neither does ELF. However, we are aware of several approaches that have been used, and with potential caveats associated with each, which ELF implementers should be aware of.
Some researchers create one copy of each possible truth. While this is sometimes obvious (e.g., if a person is listed with two birth events), it is sometimes very much not obvious (e.g., a person listed with two residences might have lived in both places, or the researcher might be unsure which place is correct). Implementers should avoid suggesting either meaning was intended by the creators of data they import.
Some researchers create multiple instances of a single-value substructure,
such as an [elf:Event] with several [elf:PLACE_STRUCTURE]s,
one for each possible location of the event.
Depending on how you read it, this usage can be seen as prohibited by GEDCOM
or permitted as an extension; it is definitely permitted as an extension in ELF.
Because of this ambiguity in GEDCOM, some tools are likely to have trouble
reading data in this format.
Additionally, it is not unambiguously talking about uncertainty either;
a researcher might believe that a single event occurred in two locations or the like.
Some researchers include just one version in the data (or none at all)
and add [elf:NOTE_STRUCTURE]s that describe the alternatives.
Assuming clear writing and a shared language, these can be fairly unambiguous
but almost never understandable by software.
None of the above is clearly the right solution, nor does any one appear to be the most common in existing data. While a future version of this specification might include extensions to handle uncertainty, ELF 1.0.0 is intended to mirror GEDCOM closely and does not include any such extension.
A structure consists of the following parts:
Structure type : Each structure has a structure type, identified by a term called its structure type identifier. Each structure type has a defined semantic meaning, supertype, and permitted payload.
The dataset itself is not a *structure*, but may be treated as one in many ways.
Its *structure type identifier* is `[elf:Document]`.
Payload : Each structure has at most one of the following payload types:
- A **pointer** to another *structure*, which *must* be a *record* within the same *dataset*.
- A *string* or subtype thereof.
Superstructure : Each structure has at most exactly one superstructure, which is either another structure or the dataset itself.
A *structure* is said to be **within** its *superstructure*
and also *within* everything its *superstructure* is *within*, recursively.
A *structure* *must not* be *within* itself.
Substructures : Each structure may contain any number of substructures; by definition, X is a substructure of Y if and only if Y is the superstructure of X.
If a *structure* contains more than one *substructure* with the same *structure type*,
those *substructures* are stored in a specific order.
However, the order of *substructures* with different *structure types* is not preserved by their *superstructure*.
Unless otherwise specified in the definition of a particular *structure*,
*substructures* with the same *structure type*
*shall* be interpreted as being in preference order, with the first such *substructure* being most preferred.
{.note ...} The exact meaning of "preferred" is not defined either here nor in any known GEDCOM standard. For example, when seeing multiple names, one if preferred by virtue of being first but implementations should not infer that that one was preferred by the individual in question nor by any particular contributor to the dataset.
When a specific order of substructures is suggested or required by the data model
(for example, [elf:CHILD_POINTER]s should be in birth order)
or when distinct semantics are present in each substructure
(for example, [elf:CHILD_TO_FAMILY_LINK]s to both birth and adoptive families)
user interfaces are recommended to either present all such information, not just the first listed;
or to clearly indicate that additional information is being elided.
{/}
{.example ...} Given the following data
0 @I1@ INDI
1 NAME Henry /Herman/
1 NAME Henry /Harmon/a view using only a single name variant should use the first (Herman, not Harmon) because it comes first and is thus interpreted as being preferred. {/}
Within this standard document, a postfix shorthand notation is used to indicate the expected cardinality of substructures of a structure:
-
"*" indicates zero or more.
-
"?" indicates either zero or one. If more than one substructure of thus type is present, all but the first are considered extensions.
-
"!" indicates exactly one. If more than one substructure of thus type is present, all but the first are considered extensions. If zero are present, the superstructure is considered an extension.
{.ednote} Basic concepts defines both the subtype of a datatype and the subclass of a class. Neither applies here: datatypes are simple types without substructures and classes define contexts for terms, not types.
Each structure type may have any number of direct supertypes, which are also structure types. The set of supertypes of a structure type contains all of its direct supertypes and the supertypes of all of its supertypes, recursively.
Be definition, a structure types semantics includes the union of the semantics of all of its supertypes. This may include permitted payloads and the meaning of substructures. A structure type must not inherit from a set of supertypes that contain contradictory semantics.
{.ednote} The above text is overly vague and needs tightening up.
{.ednote ...} Working notes on inheritance semantics:
A subtype could inherit
- its supertype's substructures (1)
- and their tags (1a)
- with optional substructures made required (1b)
- with new substructures added (1c)
- its supertype's payload (2)
- with additional constraints (2a)
- with addition of payload to payload-lacking structures (2b)
- its supertype's superstructures (3)
- and the supertype's tag within each superstructure (3a)
- with a provided different tag within each superstructure (3b)
However, not all of these can be provided and maintain consistency. My current belief is we cannot have (3a) and I'm not sure about (3b).
I'm confident (3a) cannot work because tags are the only provided means of determining the type of a substructure.
I think (3b) can work, but it raises a question when a structure has a required substructure and that substructure type has a subtype. GEDCOM expects every 1 EVEN to contain a 2 TYPE; if there is instead a 2 XYZ where XYZ is a subtype of TYPE, GEDCOM parsers may reject the data as ill-formed. My gut is to only permit (3b) if the supertype is abstract. Without either (3a) or (3b), (3) is meaningless.
A few constraints to make inheritance work:
-
If an application finds a subtype it does not understand, but does understand its supertype, it must not create or edit an instance of the subtype using its knowledge of the supertype. Doing so would violate (1b), (1c), (2a), and (2b).
-
No structure type may inherit from two or more supertypes that share a common substructure unless all of the following are met:
- Each supertype uses the same tag for the substructure. This is required because tags are lost on deserialisation so the association of particular substructures with particular supertypes via tag are not preserved.
- The semantic meaning of the substructure type is identical in each supertype. This is required because all substructure values will be shared by both supertypes, so any difference will create conflict.
It may be simpler to forbid common-substructure supertypes altogether...
-
As a corollary, if a new structure type defines itself as a substructure of two different superstructures, it must define itself as having the same tag and same semantics in both (to avoid creating conflicts with other multiple inheritance situations) unless no substructure could inherit from both because of one of the other constraints listed here.
-
No structure type may inherit from two or more supertypes that have the same tag for distinct substructure types.
I am not fully convinced that the above limitations are sufficient, but do not have counter-examples for them (yet). {/}
Some structure types are abstract, meaning they must not be identified as the structure type of any structure. Their purpose is to provide inherited semantics via being used as supertypes.
The following abstract types are presented in alphabetical order.
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
An elf:Agent structure represents an entity that may be contacted, such as a person, corporation, or archive.
Supertype
: [elf:Structure]
Substructures
: [elf:ADDRESS] ?
: [elf:ADDRESS_WEB_PAGE] *
: [elf:ADDRESS_FAX] *
: [elf:ADDRESS_EMAIL] *
: [elf:PHONE_NUMBER] *
Subtypes
: [elf:NAME_OF_BUSINESS]
: [elf:REPOSITORY_RECORD]
: [elf:SUBMITTER_RECORD]
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
This supertype was introduced in GEDCOM and encompasses all details about individuals and families to which a time and/or place may be reasonably attached, whether they be events or attributes. However, it is not used for some of the core structural connections between individuals and families used to structure traditional family trees.
Supertype
: [elf:Structure]
Superstructures : None
Substructures
: [elf:EVENT_OR_FACT_CLASSIFICATION] ?
: [elf:DATE_VALUE] ?
: [elf:PLACE_STRUCTURE] ?
: [elf:ADDRESS] ?
: [elf:RESPONSIBLE_AGENCY] ?
: [elf:RELIGIOUS_AFFILIATION] ?
: [elf:CAUSE_OF_EVENT] ?
: [elf:RESTRICTION_NOTICE] ?
: [elf:NOTE_STRUCTURE] *
: [elf:SOURCE_CITATION] *
: [elf:MULTIMEDIA_LINK] *
Subtypes
: [elf:FamilyEvent]
: [elf:IndividualAttribute]
: [elf:IndividualEvent]
{.note} GEDCOM suggested that elf:Event was a subtype of [elf:Agent] and thus could have [elf:ADDRESS_WEB_PAGE], etc., inside; this appears to be a mistake as almost no historical event has any of that information.
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
This supertype was introduced in GEDCOM and encompasses all details about families to which a time and/or place may be reasonably attached, whether they be events or attributes. However, it is not used for some of the core structural connections between individuals and families used to structure traditional family trees.
Supertype
: [elf:Event]
Superstructures
: [elf:FAM_RECORD]
Substructures
: [elf:Parent1Age] ?
: [elf:Parent2Age] ?
Subtypes
: [elf:ANNULMENT]
: [elf:CENSUS#Family]
: [elf:DIVORCE]
: [elf:DIVORCE_FILED]
: [elf:ENGAGEMENT]
: [elf:MARRIAGE_BANN]
: [elf:MARRIAGE_CONTRACT]
: [elf:MARRIAGE]
: [elf:MARRIAGE_LICENSE]
: [elf:MARRIAGE_SETTLEMENT]
: [elf:RESIDENCE]
: [elf:EVENT#Family]
Payload : A string, which may be limited by subtypes.
The special value `Y` indicates an assertion that the event in question did occur,
even if it has no subordinate date or place.
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
This supertype was introduced in GEDCOM and encompasses all non-event details about individuals. However, it is not used for some of the core structural connections between individuals and families used to structure traditional family trees.
Supertype
: [elf:Event]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Substructures : inherited
Subtypes
: [elf:CASTE_NAME]
: [elf:PHYSICAL_DESCRIPTION]
: [elf:SCHOLASTIC_ACHIEVEMENT]
: [elf:NATIONAL_ID_NUMBER]
: [elf:NATIONAL_OR_TRIBAL_ORIGIN]
: [elf:COUNT_OF_CHILDREN#Individual]
: [elf:COUNT_OF_MARRIAGES]
: [elf:OCCUPATION]
: [elf:POSSESSIONS]
: [elf:RELIGIOUS_AFFILIATION#Individual]
: [elf:RESIDES_AT]
: [elf:SOCIAL_SECURITY_NUMBER]
: [elf:NOBILITY_TYPE_TITLE]
: [elf:ATTRIBUTE_DESCRIPTOR]
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
This supertype was introduced in GEDCOM and encompasses all events that an individual engaged with. However, it is not used for some of the core structural connections between individuals and families used to structure traditional family trees.
Supertype
: [elf:Event]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Substructures
: [elf:AGE_AT_EVENT]
Subtypes
: [elf:BIRTH]
: [elf:CHRISTENING]
: [elf:DEATH]
: [elf:BURIAL]
: [elf:CREMATION]
: [elf:ADOPTION]
: [elf:BAPTISM]
: [elf:BAR_MITZVAH]
: [elf:BAS_MITZVAH]
: [elf:BLESSING]
: [elf:ADULT_CHRISTENING]
: [elf:CONFIRMATION]
: [elf:FIRST_COMMUNION]
: [elf:ORDINATION]
: [elf:NATURALIZATION]
: [elf:EMIGRATION]
: [elf:IMMIGRATION]
: [elf:CENSUS#Individual]
: [elf:PROBATE]
: [elf:WILL]
: [elf:GRADUATION]
: [elf:RETIREMENT]
: [elf:EVENT#Individual]
Payload : A string, which may be limited by subtypes.
The special value `Y` indicates an assertion that the event in question did occur,
even if it has no subordinate date or place.
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
{.ednote} This supertype is added primarily as a place-holder for potential future extensions to support more general models of families.
Supertype
: [elf:Structure]
Subtypes
: [elf:PARENT1_POINTER]
: [elf:PARENT2_POINTER]
Payload
: A pointer to an [elf:INDIVIDUAL_RECORD]
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
This supertype is a convenience to represent the set of structured name substructures shared by various personal name structures.
Supertype
: [elf:Structure]
Substructures
: [elf:NAME_PIECE_PREFIX] ?
: [elf:NAME_PIECE_GIVEN] ?
: [elf:NAME_PIECE_NICKNAME] ?
: [elf:NAME_PIECE_SURNAME_PREFIX] ?
: [elf:NAME_PIECE_SURNAME] ?
: [elf:NAME_PIECE_SUFFIX] ?
: [elf:NOTE_STRUCTURE] *
: [elf:SOURCE_CITATION] *
Subtypes
: [elf:PERSONAL_NAME_STRUCTURE]
: [elf:NAME_PHONETIC_VARIATION]
: [elf:NAME_ROMANIZED_VARIATION]
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
A record is a core element of the dataset. Records must not be substructures of any structure. Pointers may only point to records.
Supertype
: [elf:Structure]
Superstructures
: [elf:Document]
Substructures
: [elf:AUTOMATED_RECORD_ID] ?
: [elf:CHANGE_DATE] ?
: [elf:NOTE_STRUCTURE] *
: [elf:USER_REFERENCE_NUMBER] *
Subtypes
: [elf:FAM_RECORD]
: [elf:INDIVIDUAL_RECORD]
: [elf:MULTIMEDIA_RECORD]
: [elf:NOTE_RECORD]
: [elf:REPOSITORY_RECORD]
: [elf:SOURCE_RECORD]
: [elf:SUBMITTER_RECORD]
This is an abstract datatype and should not be used as the structure type identifier of any concrete structure.
This represents the top of the type hierarchy and has no semantics of its own.
The following concrete types are presented in alphabetical order. Metadata types are presented in the following section.
Supertype
: [elf:Structure]
Superstructures
: [elf:ADDRESS]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
The city, town, or similar name in an address.
Default tag
: CITY
Supertype
: [elf:Structure]
Superstructures
: [elf:ADDRESS]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
The nation, country, or similar name in an address.
Default tag
: CTRY
Supertype
: [elf:Structure]
Superstructures
: [elf:Agent]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
This contains an email address.
It is *recommended* that this match production `addr-spec` of [RFC 5322].
Default tag
: EMAIL
: EMAI
Supertype
: [elf:Structure]
Superstructures
: [elf:Agent]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
This contains a telephone number that will connect to a fax machine.
It is *recommended* that this be an international telephone number.
{.ednote} Add appropriate reference to ITU-T T.4 (I think; I'm not up on these standards)
Default tag
: FAX
Supertype
: [elf:Structure]
Superstructures
: [elf:ADDRESS]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
The first line of the address, preceding the city.
.
Default tag
: ADR1
Supertype
: [elf:Structure]
Superstructures
: [elf:ADDRESS]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
The second line of the address, preceding the city.
Default tag
: ADR2
Supertype
: [elf:Structure]
Superstructures
: [elf:ADDRESS]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
The third line of the address, preceding the city.
Default tag
: ADR3
Supertype
: [elf:Structure]
Superstructures
: [elf:ADDRESS]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 10 characters.
The postal code of this address, as defined and used by the postal system in the area.
Default tag
: POST
Supertype
: [elf:Structure]
Superstructures
: [elf:ADDRESS]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
The state, province, or similar name in the area.
Default tag
: STAE
Supertype
: [elf:Structure]
Superstructures
: [elf:Agent]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
This *should* contain a single IRL, as defined in [RFC 1736].
{.ednote} Look up RFC 1736 and make sure the above is correct.
Default tag
: WWW
Supertype
: [elf:Structure]
Superstructures
: [elf:Event]
: [elf:Agent]
Substructures
: [elf:ADDRESS_LINE1]
: [elf:ADDRESS_LINE2]
: [elf:ADDRESS_LINE3]
: [elf:ADDRESS_CITY]
: [elf:ADDRESS_STATE]
: [elf:ADDRESS_POSTAL_CODE]
: [elf:ADDRESS_COUNTRY]
Payload : A block string of arbitrary length.
The fully-formatted address, as it would appear for shipment labels.
This *should not* be omitted even if all of its information is contained in substructures.
Default tag
: ADDR
Supertype
: [elf:Structure]
Superstructures
: [elf:ADOPTIVE_FAMILY]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 4 characters.
Known values include {`HUSB`, `WIFE`, `BOTH`}.
`HUSB` means the adoption was to the individual indicated by the `[elf:PARENT1_POINTER]` of the `[elf:FAM_RECORD]` pointed to by the payload of the containing superstructure;
`WIFE` means the adoption was to the individual indicated by the `[elf:PARENT2_POINTER]`pointed to by the payload of the containing superstructure;
and `BOTH` means both of those individuals were part of the adoption.
Default tag
: ADOP
The creation of a parent-child relationship not associated with birth.
Supertype
: [elf:IndividualEvent]
Substructures
: [elf:ADOPTIVE_FAMILY] ?
Default tag
: ADOP
Supertype
: [elf:Structure]
Superstructures
: [elf:ADOPTION]
Substructures
: [elf:ADOPTED_BY_WHICH_PARENT]
Payload
: A pointer to a [elf:FAM_RECORD].
The pointed-to record describes the family unit into which the individual was adopted.
Default tag
: FAMC
Adult christening, a religious rite in some Christian denominations typically performed when converting to the religion.
Supertype
: [elf:IndividualEvent]
Default tag
: CHRA
Supertype
: [elf:Structure]
Superstructures
: [elf:IndividualEvent]
: [elf:Parent1Age]
: [elf:Parent2Age]
Payload
: A line string in the lexical space of the elf:Age datatype
defined in §6 of [ELF Dates].
Default tag
: AGE
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Payload
: A pointer to an [elf:INDIVIDUAL_RECORD]
Points to a different `[elf:INDIVIDUAL_RECORD]` that may describe the same historical individual as the superstructure.
Default tag
: ALIA
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Payload
: A pointer to an [elf:SUBMITTER_RECORD]
Indicates that the pointed-to `[elf:SUBMITTER_RECORD]` describes someone interested in the ancestors of the individual described by the superstructure.
Default tag
: ANCI
Declaring a marriage to be invalid, as though it had never occurred.
Supertype
: [elf:FamilyEvent]
Default tag
: ANUL
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Substructures
: [elf:RELATION_IS_DESCRIPTOR] !
: [elf:SOURCE_CITATION] *
: [elf:NOTE_STRUCTURE] *
Payload
: A pointer to a [elf:INDIVIDUAL_RECORD]
{.ednote} While GEDCOM unambiguously stated this was a pointer to an INDIVIDUAL_RECORD, it also contained an example (under the definition of RELATION_IS_DESCRIPTOR) where it was a pointer to a SUBMITTER_RECORD instead.
Default tag
: ASSO
A generic attribute, the type of which must be more fully described in a [elf:EVENT_OR_FACT_CLASSIFICATION] substructure.
Supertype
: [elf:IndividualAttribute]
Substructures
: [elf:EVENT_OR_FACT_CLASSIFICATION] !
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
A textual description of the specific attribute; typically more specific than the generic attribute type classification of the `[elf:EVENT_OR_FACT_CLASSIFICATION]` substructure.
Default tag
: FACT
Supertype
: [elf:Structure]
Superstructures
: [elf:Record]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 12 characters.
A record identifier (numeric or textual) that is supposed to be unique within an originating system.
Since there is no indication of which system, nor a mechanism for spanning systems,
this has little value when communicating between systems.
Default tag
: RIN
Baptism, a common Christian rite, typically involving water and indicating entry into a particular faith or denomination, performed at different ages in different denominations.
Supertype
: [elf:IndividualEvent]
Default tag
: BAPM
Bar Mitzvah, a Jewish rite (typically for 13-year-old boys).
Supertype
: [elf:IndividualEvent]
Default tag
: BARM
Bas Mitzvah, a Jewish rite (typically for 13-year-old girls).
Supertype
: [elf:IndividualEvent]
Default tag
: BASM
Binary object was in GEDCOM 5.5 but removed from GEDCOM 5.5.1. Implementations should be able to parse them, but should not generate new binary objects.
{.ednote} The definition of the base-64 encoding used the terminology "byte" when GEDCOM had elsewhere defined its stream as consisting of characters, not bytes. It is unclear to me if it is possible to follow the spec for an encoding that does not permit byte 0xFF as a single character.
Supertype
: [elf:Structure]
Superstructures
: [elf:MULTIMEDIA_RECORD]
Substructures : None
Payload : A block string containing two or more lines of base-64 encoded data, in the custom format described below.
The first line of a blob is always empty.
Each subsequent line is between 4 and 72 characters long, encoded in a base-64 format that differs from other base-64 encodings in two ways.
First, it uses byte 0xFF as padding instead of the more common U+003D (EQUALS SIGN `=`)
(how to represent the padding when byte 0xFF is not a legal character in the encoding is not defined by this specification).
Second, it maps six-bit values to code points as follows:
| Byte range | Code point mapping |
|------------|--------------------|
| 0x00--0x0B | byte + 0x2E |
| 0x0C--0x25 | byte + 0x35 |
| 0x25--0x3F | byte + 0x3B |
See also the discussion under `[elf:CONTINUED_BINARY_OBJECT]` for how multiple `elf:BINARY_OBJECT` payloads are combined to represent large binary values.
Default tag
: BLOB
The exiting of the womb.
Supertype
: [elf:IndividualEvent]
Substructures
: [elf:WITHIN_FAMILY] ?
Default tag
: BIRT
A religious rite invoking divine favour on an individual.
Supertype
: [elf:IndividualEvent]
Default tag
: BLES
The depositing of the body (in whole or in part) of the deceased.
Supertype
: [elf:IndividualEvent]
Default tag
: BRI
Supertype
: [elf:IndividualAttribute]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The social, religious, or racial caste tow which an individual belongs.
Default tag
: CAST
Supertype
: [elf:Structure]
Superstructures
: [elf:Event]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
Introduced to record the cause of death as a substructure to a `[elf:DEATH]` structure, but permitted under any event in case a cause of the event is known.
Default tag
: CAUS
An inventory of persons or households in a population.
Supertype
: [elf:FamilyEvent]
Default tag
: CENS
An inventory of persons or households in a population.
Supertype
: [elf:IndividualEvent]
Default tag
: CENS
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_CITATION]
Payload
: A line string containing a numeric value.
Known values include {0, 1, 2, and 3}.
A ranking hint for display: if two `[elf:SOURCE_CITATION]`s contain `elf:CERTAINTY_ASSESSMENT`s with different payloads, the numerically larger `elf:CERTAINTY_ASSESSMENT` may be displayed as being inside a more reliable `[elf:SOURCE_CITATION]` than is the numerically smaller payload.
GEDCOM defined the four specific values as having the following meanings
> 0 = Unreliable evidence or estimated data
>
> 1 = Questionable reliability of evidence (interviews, census, oral genealogies, or potential for bias for example, an autobiography)
>
> 2 = Secondary evidence, data officially recorded sometime after event
>
> 3 = Direct and primary evidence used, or by dominance of the evidence
{.note} It is unclear that GEDCOM's four categories have the relative reliability their ordering suggests, nor that elf:CERTAINTY_ASSESSMENTs in extant files contain meaningful information. It is not difficult to find example GEDCOM where all [elf:SOURCE_CITATION]s have a elf:CERTAINTY_ASSESSMENT with payload 3 even when some clearly cite sources providing secondary evidence of the facts containing the citation.
Default tag
: QUAY
Supertype
: [elf:Structure]
Superstructures
: [elf:CHANGE_DATE]
Substructures
: [elf:TIME_VALUE] ?
Payload
: A line string in the lexical space of the elf:DateExact
datatype defined in §4.1.1 of [ELF Dates].
Indicates the last change to the containing structure.
Default tag
: DATE
Supertype
: [elf:Structure]
Superstructures
: [elf:Record]
Substructures
: [elf:CHANGE_DATE_DATE] !
: [elf:NOTE_STRUCTURE] *
Payload : None
Default tag
: CHAN
{.ednote} GEDCOM uses the token CHANGE_DATE in two ways. Page 31 defines what we call [elf:CHANGE_DATE], a structure containing a date and an arbitrary number of notes; page 44 defines what we call [elf:CHANGE_DATE_DATE], a payload-only format structure.
Supertype
: [elf:Structure]
Superstructures
: [elf:CHILD_TO_FAMILY_LINK]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 15 characters.
Contains a description of the confidence that this relationship exists.
Known values include {`challenged`, `disproven`, `proven`}.
No matter the contents, there *should* be a `[elf:NOTE_STRUCTURE]` within this structure's superstructure that describes the proof or challenge.
Default tag
: STAT
A pointer one of the children in a family.
The preferred order of the children pointers within a family structure is chronological by birth.
Supertype
: [elf:Structure]
Superstructures
: [elf:FAM_RECORD]
Payload
: A pointer to an [elf:INDIVIDUAL_RECORD]
It *must* be the case that the pointed-to `[elf:INDIVIDUAL_RECORD]` contains a `[elf:CHILD_TO_FAMILY_LINK]` pointing to the superstructure of this structure.
Default tag
: CHIL
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Substructures
: [elf:PEDIGREE_LINKAGE_TYPE] ?
: [elf:CHILD_LINKAGE_STATUS] ?
: [elf:NOTE_STRUCTURE] *
Payload
: A pointer to a [elf:FAM_RECORD]
It *must* be the case that the pointed-to `[elf:FAM_RECORD]` contains a `[elf:CHILD_POINTER]` pointing to the superstructure of this structure.
Default tag
: FAMC
A religious rite occurring at or near birth.
Supertype
: [elf:IndividualEvent]
Substructures
: [elf:WITHIN_FAMILY] ?
Default tag
: CHR
Confirmation, a religious rite in some Christian denominations associated with gaining full fellowship in the religion and/or receiving the Holy Ghost.
Supertype
: [elf:IndividualEvent]
Default tag
: CONF
Binary object was in GEDCOM 5.5 but removed from GEDCOM 5.5.1. Implementations should be able to parse them, but should not generate new binary objects.
Supertype
: [elf:Structure]
Superstructures
: [elf:MULTIMEDIA_RECORD]
Substructures : None
Payload
: A pointer to a [elf:MULTIMEDIA_RECORD].
Used to split `elf:BINARY_OBJECT`s across multiple records.
Prior to decoding, the payloads of all `elf:BINARY_OBJECT` in the superstructure
should be concatenated in the order in which they appear,
and then concatenated with the `elf:BINARY_OBJECT`s in the pointed-to record
and those pointed to by its `elf:CONTINUED_BINARY_OBJECT`, recursively.
Default tag
: OBJE
Supertype
: [elf:Structure]
Superstructures
: [elf:FAM_RECORD]
Payload : A line string taking the form of a decimal number. It is RECOMMENDED that implementations support payloads of at least 3 characters.
The total number of children this family unit had,
either at some (unspecified) point in time or in total its entire existence.
This does not need to match the number of children identified through `[elf:CHILD_POINTER]` substructures of the containing superstructure.
Default tag
: NCHI
{.ednote} It seems odd to me that elf:COUNT_OF_CHILDREN#Family is not a elf:FamilyEvent (or elf:FamilyAttribute, though no such supertype currently exists) as surely the number of children of a family would need sourcing and an as-of date? Should we leave it as a stand-alone structure, or boost it to event status?
Supertype
: [elf:IndividualAttribute]
Payload : A line string taking the form of a decimal number. It is RECOMMENDED that implementations support payloads of at least 3 characters.
The total number of children this person ever had.
This does not need to match the number of children individually identified in the dataset.
Default tag
: NCHI
Supertype
: [elf:IndividualAttribute]
Payload : A line string taking the form of a decimal number. It is RECOMMENDED that implementations support payloads of at least 3 characters.
The total number of marriages this person ever had.
This does not need to match the number of marriages individually identified in the dataset.
Default tag
: NMR
The burning of the body (in whole or in part) of the deceased.
Supertype
: [elf:IndividualEvent]
Default tag
: CREM
Supertype
: [elf:Structure]
Superstructures
: [elf:EVENTS_RECORDED]
Payload
: A line string in the lexical space of the elf:DatePeriod
datatype defined in §3.4 of [ELF Dates].
Indicates the period during which the source recorded events.
Default tag
: DATE
Supertype
: [elf:Structure]
Superstructures
: [elf:Event]
Payload
: A line string in the lexical space of the elf:DateValue
datatype defined in §3.3 of [ELF Dates].
Indicates when the event or attribute described by the containing structure occurred or was witnessed.
Default tag
: DATE
The end of life.
Supertype
: [elf:IndividualEvent]
Default tag
: DEAT
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Payload
: A pointer to an [elf:SUBMITTER_RECORD]
Indicates that the pointed-to `[elf:SUBMITTER_RECORD]` describes someone interested in the descendants of the individual described by the superstructure.
Default tag
: DESI
Supertype
: [elf:Structure]
Superstructures
: [elf:MULTIMEDIA_RECORD] -- GEDCOM 5.5
: [elf:MULTIMEDIA_FILE_REFERENCE] -- GEDCOM 5.5.1
: [elf:MULTIMEDIA_LINK]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 248 characters.
The title of a work, record, item, or object.
Default tag
: TITL
The legal action expressing intent to divorce.
Supertype
: [elf:FamilyEvent]
Default tag
: DIVF
The ending of a marriage between still-living individuals.
Supertype
: [elf:FamilyEvent]
Default tag
: DIV
The departure from the nation or land in which one has nativity or citizenship.
Supertype
: [elf:IndividualEvent]
Default tag
: EMIG
The agreement of a couple to enter into a marriage in the future.
Supertype
: [elf:FamilyEvent]
Default tag
: ENGA
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_CITATION_DATA]
Payload
: A line string in the lexical space of the elf:DateValue
datatype defined in §3.3 of [ELF Dates].
Indicates when the portion of the source being cited was entered into the source.
Default tag
: DATE
A generic event, the type of which should be more fully described in a [elf:EVENT_OR_FACT_CLASSIFICATION] substructure.
Supertype
: [elf:FamilyEvent]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
A textual description of the specific event; typically more specific than the generic event type classification of the `[elf:EVENT_OR_FACT_CLASSIFICATION]` substructure.
Unlike other `[elf:FamilyEvent]`s, `Y` is not a special value.
`elf:EVENT#Family` events are always assertions that the event occurred.
Default tag
: EVEN
A generic event, the type of which should be more fully described in a [elf:EVENT_OR_FACT_CLASSIFICATION] substructure.
Supertype
: [elf:IndividualEvent]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
A textual description of the specific event; typically more specific than the generic event type classification of the `[elf:EVENT_OR_FACT_CLASSIFICATION]` substructure.
Unlike other `[elf:FamilyEvent]`s, `Y` is not a special value.
`elf:EVENT#Family` events are always assertions that the event occurred.
{.ednote} GEDCOM does not list this payload for individual EVEN, only family EVEN, but other text in GEDCOM suggests that this was an oversight, not an intentional omission.
Default tag
: EVEN
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD_DATA]
Substructures
: [elf:DATE_PERIOD]
: [elf:SOURCE_JURISDICTION_PLACE]
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 90 characters.
A list of valid payload values of `[elf:EVENT_TYPE_CITED_FROM]`.
Indicates that the source includes documentation of these events or attributes.
Default tag
: EVEN
Supertype
: [elf:Structure]
Superstructures
: [elf:Event]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
A classification for the superstructure's category, more precise than its type alone provides but generic enough to be anticipated to be re-used.
Default tag
: TYPE
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_CITATION]
Substructures
: [elf:ROLE_IN_EVENT]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 15 characters.
Known values include
{`CAST`, `EDUC`, `NATI`, `OCCU`, `PROP`, `RELI`, `RESI`, `TITL`, `FACT`,
`ANUL`, `CENS`, `DIV`, `DIVF`, `ENGA`, `MARR`, `MARB`, `MARC`, `MARL`, `MARS`,
`ADOP`, `BIRT`, `BAPM`, `BARM`, `BASM`, `BLES`, `BURI`, `CENS`, `CHR`,
`CHRA`, `CONF`, `CREM`, `DEAT`, `EMIG`, `FCOM`, `GRAD`, `IMMI`, `NATU`,
`ORDN`, `RETI`, `PROB`, `WILL`,
`EVEN`}.
Indicates that the cited source was created to document the event or attribute
described by the subtype of `elf:Event` whose default tag is the provided value.
{.example ...}
A marriage certificate may document the spouses' birth dates;
however, its elf:EVENT_TYPE_CITED_FROM's payload should be MARR, not BIRT.
{/}
Default tag
: EVEN
Used to record couple and parent/child relationships.
Because of the social context in which GEDCOM was first created and because elf:FAM_RECORDs are used in some software applications to present binary ancestry trees and n-ary descendancy trees, each elf:FAM_RECORD is limited to having at most one "first-position" parent; at most one "second-position" parent; and any number of ordered children. GEDCOM explicitly stated that the first-position parent was male and the second-position parent was female; that is not always true of how GEDCOM has been used in practice and MUST NOT be assumed by any conformant ELF implementation.
Supertype
: [elf:Record]
Superstructures
: [elf:Document]
Substructures
: [elf:RESTRICTION_NOTICE] ?
: [elf:FamilyEvent] *
: [elf:PARENT1_POINTER] ?
: [elf:PARENT2_POINTER] ?
: [elf:CHILD_POINTER] *
: [elf:COUNT_OF_CHILDREN#Family] ?
: [elf:MULTIMEDIA_LINK] *
: [elf:SOURCE_CITATION] *
: [elf:SUBMITTER_POINTER] *
Payload : None
Default tag
: FAM
First communion, a religious rite in many Christian denominations associated with first partaking of the communion of the Lord's Supper.
Supertype
: [elf:IndividualEvent]
Default tag
: FCOM
The conclusion of formal education.
Supertype
: [elf:IndividualEvent]
Default tag
: GRAD
The entering of a nation or land in which one does not have nativity or citizenship.
Supertype
: [elf:IndividualEvent]
Default tag
: IMMI
A representation of a historical individual, together with the facts and events believed to apply to that individual and the sources of those data.
Supertype
: [elf:Record]
Superstructures
: [elf:Document]
Substructures
: [elf:RESTRICTION_NOTICE] ?
: [elf:PERSONAL_NAME_STRUCTURE] *
: [elf:SEX_VALUE] ?
: [elf:IndividualEvent] *
: [elf:IndividualAttribute] *
: [elf:CHILD_TO_FAMILY_LINK] *
: [elf:SPOUSE_TO_FAMILY_LINK] *
: [elf:ASSOCIATION_STRUCTURE] *
: [elf:ALIAS_POINTER] *
: [elf:ANCESTOR_INTEREST_POINTER] *
: [elf:DESCENDANT_INTEREST_POINTER] *
: [elf:MULTIMEDIA_LINK] *
: [elf:SOURCE_CITATION] *
: [elf:SUBMITTER_POINTER] *
{.note} GEDCOM permitted a PERMANENT_RECORD_FILE_NUMBER with tag RFN, the value of which was under-defined and not included in this one.
Payload : None
Default tag
: INDI
Supertype
: [elf:Structure]
Superstructures
: [elf:SUBMITTER_RECORD]
Substructures : None
Payload : A line string matching the Language Tag microformat.
Indicates a language in which the person described by the superstructure prefers to communicate.
Default tag
: LANG
Contains the location of a place in a global coordinate system.
Supertype
: [elf:Structure]
Superstructures
: [elf:PLACE_STRUCTURE]
Substructures
: [elf:PLACE_LATITUDE] !
: [elf:PLACE_LONGITUDE] !
Payload : None
Default tag
: MAP
A public notice of an intent to marry.
Supertype
: [elf:FamilyEvent]
Default tag
: MARB
A formal contractual agreement to marry.
Supertype
: [elf:FamilyEvent]
Default tag
: MARC
Obtaining a legal license to marry.
Supertype
: [elf:FamilyEvent]
Default tag
: MARL
A legal arrangement to modify property rights upon marriage.
Supertype
: [elf:FamilyEvent]
Default tag
: MARS
The creation of a family unit (via a legal, religious, customary, common-law, or other form of union).
Supertype
: [elf:FamilyEvent]
Default tag
: MARR
Supertype
: [elf:Structure]
Superstructures
: [elf:MULTIMEDIA_RECORD]
: [elf:MULTIMEDIA_LINK]
Substructures
: [elf:MULTIMEDIA_FORMAT] !
: [elf:DESCRIPTIVE_TITLE] ?
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 30 characters.
Contains locator information (such as a file path or IRL) for a file containing auxiliary data.
{.ednote} GEDCOM is vague on payload format. Presumably there exist a variety of formats in the wild. Should we perform a survey and see if we can provide guidance on payload format?
Default tag
: FILE
Supertype
: [elf:Structure]
Superstructures
: [elf:MULTIMEDIA_RECORD] -- GEDCOM 5.5
: [elf:MULTIMEDIA_FILE_REFERENCE] -- GEDCOM 5.5.1
: [elf:MULTIMEDIA_LINK]
Substructures
: [elf:SOURCE_MEDIA_TYPE] ?
Payload
: A line string. Known values include {bmp, gif, jpg, ole, pcx, tif, wav}.
Indicates the format of the multimedia data associated with the superstructure of the `elf:MULTIMEDIA_FORMAT` structure.
{.ednote} Should we expand this to allow MIME-type as well as the seven known Windows-style file endings?
Default tag
: FORM
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_CITATION]
: [elf:FAM_RECORD]
: [elf:INDIVIDUAL_RECORD]
: [elf:SOURCE_RECORD]
: [elf:SUBMITTER_RECORD]
: [elf:Event]
Substructures
: [elf:MULTIMEDIA_FILE_REFERENCE] *
: [elf:DESCRIPTIVE_TITLE] ?
: [elf:MULTIMEDIA_FORMAT] ? -- GEDCOM 5.5
Payload
: Either a pointer to a [elf:MULTIMEDIA_RECORD] or none.
If the payload is a pointer, it *should not* contain substructures.
Default tag
: OBJE
{.ednote} TO DO: review GEDCOM 5.5 to make sure this is right
The form of this record was changed between GEDCOM 5.5 and GEDCOM 5.5.1. Implementations should accept both formats but export only 5.5.1 format.
Supertype
: [elf:Record]
Superstructures
: [elf:Document]
Substructures
: [elf:MULTIMEDIA_FILE_REFERENCE] * -- GEDCOM 5.5.1
: [elf:MULTIMEDIA_FORMAT] ! -- GEDCOM 5.5
: [elf:DESCRIPTIVE_TITLE] ? -- GEDCOM 5.5
: [elf:CONTINUED_BINARY_OBJECT] ? -- GEDCOM 5.5
: [elf:BINARY_OBJECT] ! -- GEDCOM 5.5
Payload : None
Default tag
: OBJE
Supertype
: [elf:Structure]
Superstructures
: [elf:REPOSITORY_RECORD]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The name of the repository described by the superstructure.
Default tag
: NAME
Supertype
: [elf:PersonalName]
Superstructures
: [elf:PERSONAL_NAME_STRUCTURE]
Substructures
: [elf:PHONETIC_TYPE]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
Contains a phonetic presentation of the same name as its superstructure.
Default tag
: FONE
Supertype
: [elf:Structure]
Superstructures
: [elf:PersonalName]
Substructures : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A list of given or earned names.
Default tag
: GIVN
Supertype
: [elf:Structure]
Superstructures
: [elf:PersonalName]
Substructures : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 30 characters.
A list of familiar or informal names.
Default tag
: NICK
Supertype
: [elf:Structure]
Superstructures
: [elf:PersonalName]
Substructures : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 30 characters.
A list of non-name elements traditionally placed before the proper name, such as titles.
Default tag
: NPFX
Supertype
: [elf:Structure]
Superstructures
: [elf:PersonalName]
Substructures : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 30 characters.
A list of non-name elements traditionally placed after the proper name, such as generational marks and ordinals.
Default tag
: NSFX
Supertype
: [elf:Structure]
Superstructures
: [elf:PersonalName]
Substructures : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A list of non-name elements traditionally attached to and placed before a surname of family name, such as prepositions.
Default tag
: SPFX
Supertype
: [elf:Structure]
Superstructures
: [elf:PersonalName]
Substructures : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A list of surnames and family names.
Default tag
: SURN
Supertype
: [elf:PersonalName]
Superstructures
: [elf:PERSONAL_NAME_STRUCTURE]
Substructures
: [elf:ROMANIZED_TYPE]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
Contains the same name as its superstructure, but presented using ASCII letters.
Default tag
: ROMN
Supertype
: [elf:Structure]
Superstructures
: [elf:PERSONAL_NAME_STRUCTURE]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 30 characters.
The kind of name the superstructure contains.
Known values include {`aka`, `birth`, `immigration`, `maiden`, `married`}; additional values are encouraged as appropriate.
| known value | meaning |
|:------------|:----------------------------------------|
| aka | also known as: an unofficial pseudonym |
| birth | name given at or near birth |
| immigrant | name assumed when immigrating |
| maiden | name used prior to marriage |
| married | name assumed at marriage |
{.note} GEDCOM's definition of the married payload was "name was persons previous married name," suggestion it was only to be used after the married name was no longer used; this nuanced definition does not appear to have been used in practice.
Default tag
: TYPE
Supertype
: [elf:IndividualAttribute]
Substructures
: [elf:EVENT_OR_FACT_CLASSIFICATION] !
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 30 characters.
An identifier used by a nation to a particular individual.
If an appropriate nation-specific alternative is present, it *should* be used.
Default tag
: IDNO
Supertype
: [elf:IndividualAttribute]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A group to which a person is associated, typically by birth.
Default tag
: NATI
{.ednote} GEDCOM used American spelling; should we change it to British?
The gaining of citizenship in a new nation or land.
Supertype
: [elf:IndividualEvent]
Default tag
: NATU
Supertype
: [elf:IndividualAttribute]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A title given a person associated with a local or national notion of nobility or royalty.
Default tag
: TITL
Supertype
: [elf:Record]
Superstructures
: [elf:Document]
Payload : A block string of arbitrary length.
Default tag
: NOTE
{.note} GEDCOM did not [elf:NOTE_STRUCTURE] as a substructure of elf:NOTE_RECORD, but they do appear in the wild and have valid semantics (notes about the note itself) so elf:NOTE_RECORD inherits the [elf:NOTE_STRUCTURE] substructure from [elf:Record] in this specification.
{.ednote} We list here all superstructures where a [elf:NOTE_STRUCTURE] is listed in GEDCOM.
We have discussed saying instead that a [elf:NOTE_STRUCTURE] can appear in any [elf:Structure]
(including other [elf:NOTE_STRUCTURE] as we have use cases for notes about notes)
but as that is technically a divergence from GEDCOM, we have refrained from adding it to this draft.
Supertype
: [elf:Structure]
Superstructures
: [elf:Record]
: [elf:SOURCE_RECORD_DATA]
: [elf:ASSOCIATION_STRUCTURE]
: [elf:CHILD_TO_FAMILY_LINK]
: [elf:Event]
: [elf:PersonalName]
: [elf:SOURCE_CITATION]
: [elf:SOURCE_REPOSITORY_CITATION]
: [elf:SPOUSE_TO_FAMILY_LINK]
: [elf:CHANGE_DATE]
: [elf:PLACE_STRUCTURE]
Substructures : None
Payload
: Either a pointer to a [elf:NOTE_RECORD] or a block string of arbitrary length.
Default tag
: NOTE
Supertype
: [elf:IndividualAttribute]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
What this person does as a livelihood.
Default tag
: OCCU
The bestowal of religious authority or office.
Supertype
: [elf:IndividualEvent]
Default tag
: ORDN
A pointer to the spouse or parent traditionally presented on the left fork of a vertical family tree or on the upper fork of a horizontal family tree. In a heterosexual pair union, this is traditionally the husband or father.
Supertype
: [elf:ParentPointer]
Superstructures
: [elf:FAM_RECORD]
Payload
: A pointer to an [elf:INDIVIDUAL_RECORD]
Default tag
: HUSB
A pointer to the spouse or parent traditionally presented on the right fork of a vertical family tree or on the bottom fork of a horizontal family tree. In heterosexual pair unions, this is traditionally the wife or mother.
Supertype
: [elf:ParentPointer]
Superstructures
: [elf:FAM_RECORD]
Payload
: A pointer to an [elf:INDIVIDUAL_RECORD]
Default tag
: WIFE
Supertype
: [elf:Structure]
Superstructures
: [elf:CHILD_TO_FAMILY_LINK]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 7 characters.
Contains a description of how this child is related to the superstructure's pointed-to `[elf:FAM_RECORD]`.
Known values include {`adopted`, `birth`, `foster`}.
Default tag
: PEDI
Supertype
: [elf:PersonalName]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Substructures
: [elf:NAME_TYPE]
: [elf:NAME_PHONETIC_VARIATION]
: [elf:NAME_ROMANIZED_VARIATION]
Payload : A line string matching the Personal Name microformat. It is RECOMMENDED that implementations support payloads of at least 120 characters.
In the event that this payload disagrees with the substructures of this structure, the payload *should* be taken as more correct.
Default tag
: NAME
Supertype
: [elf:Structure]
Superstructures
: [elf:NAME_PHONETIC_VARIATION]
: [elf:PLACE_PHONETIC_VARIATION]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 30 characters.
Identifies the phonetic scheme used in the superstructure.
Known values include {`hangul`, `kana`}.
{.ednote} Should we add others, like ipa?
Default tag
: TYPE
Supertype
: [elf:Structure]
Superstructures
: [elf:Agent]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 30 characters.
This contains a telephone number.
It is *recommended* that this be an international telephone number.
{.ednote} Add appropriate reference to ITU-T E.123 and E.164 (I think; I'm not up on these standards)
Default tag
: PHON
Supertype
: [elf:IndividualAttribute]
Payload : A block string of arbitrary length.
Appearance and/or other physical characteristics.
Default tag
: DSCR
{.ednote} This feels like a strange way of serializing an ordered map, and thus perhaps better defined as a pseudo-structure?
Supertype
: [elf:Structure]
Superstructures
: [elf:PLACE_STRUCTURE]
: [elf:DEFAULT_PLACE_FORMAT]
Substructures : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A list of names of what the specific components of `[elf:PLACE_STRUCTURE]` represent.
Default tag
: FORM
Degrees north or south of the equator
Supertype
: [elf:Structure]
Superstructures
: [elf:MAP_COORDINATES]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 12 characters.
Decimal degrees from the equator.
Either the letter `N` (for north) or `S` (for south), followed (without a space) by a decimal number between 0 and 90.
{.note} Only decimal degrees supported; degree-minute-second representations must not appear in this payload.
Default tag
: LATI
Supertype
: [elf:Structure]
Superstructures
: [elf:MAP_COORDINATES]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 12 characters.
Decimal degrees from the prime meridian.
Either the letter `E` (for east) or `W` (for west), followed (without a space) by a decimal number between 0 and 180.
{.note} Only decimal degrees supported; degree-minute-second representations must not appear in this payload.
Default tag
: LONG
Supertype
: [elf:Structure]
Superstructures
: [elf:PLACE_STRUCTURE]
Substructures
: [elf:PHONETIC_TYPE]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
Contains a phonetic presentation of the same place, in the same format, as its superstructure.
Default tag
: FONE
Supertype
: [elf:Structure]
Superstructures
: [elf:PLACE_STRUCTURE]
Substructures
: [elf:ROMANIZED_TYPE]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
Contains an ASCII letter presentation of the same place, in the same format, as its superstructure.
Default tag
: ROMN
Supertype
: [elf:Structure]
Superstructures
: [elf:Event]
Substructures
: [elf:PLACE_HIERARCHY] ?
: [elf:PLACE_PHONETIC_VARIATION] *
: [elf:PLACE_ROMANIZED_VARIATION] *
: [elf:MAP_COORDINATES] ?
: [elf:NOTE_STRUCTURE] *
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A list of names of regions, where each element of the list is subsumed within all subsequent elements.
If this structure has a `[elf:PLACE_HIERARCHY]` substructure or there is a default `[elf:PLACE_HIERARCHY]` defined for the dataset, then this payload *should* contain one name for each jurisdictional elements in that `[elf:PLACE_HIERARCHY]`, using empty strings in place of any unknown or non-present elements.
Default tag
: PLAC
{.note} If an individual region name contains a comma, that comma cannot be represented in the place structure format. As there is no escaping mechanism provided, it must either be omitted or replaced with a substitute marking.
Supertype
: [elf:IndividualAttribute]
Payload : A line string of arbitrary length.
A list of objects or land owned by the person.
Default tag
: PROP
The judicial actions associated with the disposition of the estate of the deceased.
Supertype
: [elf:IndividualEvent]
Default tag
: PROB
An intermediate structure to indicate the age of a spouse or parent at the time of an event.
Supertype
: [elf:Structure]
Superstructures
: [elf:FamilyEvent]
Substructures
: [elf:AGE_AT_EVENT]
Payload : None
Default tag
: HUSB
An intermediate structure to indicate the age of a spouse or parent at the time of an event.
Supertype
: [elf:Structure]
Superstructures
: [elf:FamilyEvent]
Substructures
: [elf:AGE_AT_EVENT]
Payload : None
Default tag
: WIFE
Supertype
: [elf:Structure]
Superstructures
: [elf:ASSOCIATION_STRUCTURE]
Substructures : None
Payload : A line string of arbitrary length. It is RECOMMENDED that implementations support payloads of at least 25 characters.
Describes the nature of the association described by the superstructure.
This is a directed relationship.
If the payload text is *R*,
the person described by the record pointed to by the payload of the superstructure is *P*, and
the person described by the superstructure of the superstructure is *Q*
then this payload means "*P* is *Q*'s *R*".
{.example ...} The following ELF fragment records that Galahad was employed by Arthur:
0 @arthur@ INDI
1 NAME Arthur //
1 ASSO @galahad@
2 RELA employee
0 @galahad@ INDI
1 NAME Galahad //
1 ASSO @arthur@
2 RELA employer{/}
Default tag
: RELA
Supertype
: [elf:IndividualAttribute]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The name of a religion with which the person affiliates.
Default tag
: RELI
Supertype
: [elf:Structure]
Superstructure
: [elf:Event]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The name of a religion with which the event was affiliated.
Default tag
: RELI
A representation of where a source or set of sources is located. May be formal, like a library, or informal, like the owner of a family bible.
Supertype
: [elf:Record]
: [elf:Agent]
Superstructures
: [elf:Document]
Substructures
: [elf:NAME_OF_REPOSITORY] !
Payload : None
Default tag
: REPO
Residence: either the fact of residing at, or the event of moving to, a particular location.
Supertype
: [elf:FamilyEvent]
Default tag
: RESI
Indicates that the person resided at the location indicated by the [elf:ADDRESS] substructure.
Supertype
: [elf:IndividualAttribute]
Substructures
: [elf:ADDRESS] !
Payload : None
Default tag
: RESI
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD_DATA]
: [elf:Event]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
The group or entity that was responsible for this event or data.
Default tag
: AGNC
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
: [elf:FAM_RECORD]
: [elf:Event]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 12 characters.
Specifies how the superstructure should be treated.
Known values and their meaning are listed in the following table:
Known value Meaning
-------------- ------------------------------------------------------------
confidential should not be distributed or exported
locked should not be edited
privacy has had information omitted to maintain confidentiality
Default tag
: RESN
The cessation of gainful employment, typically because sufficient wealth has been accumulated to no longer necessitate such.
Supertype
: [elf:IndividualEvent]
Default tag
: RETI
Supertype
: [elf:Structure]
Superstructures
: [elf:EVENT_TYPE_CITED_FROM]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 25 characters.
When contained within an `[elf:INDIVIDUAL_RECORD]`, indicates what role that individual played in the event described by this structure's superstructure.
It has no defined meaning (and thus *should not* be used) outside of that context.
Known values and their meanings are listed in the following table.
It is expected that additional values are also used when these are insufficient:
Known value Role the individual played in the event
------------- ------------------------------------------------------------
CHIL child
FATH father
HUSB husband
MOTH mother
SPOU spouse
WIFE wife
Default tag
: ROLE
Supertype
: [elf:Structure]
Superstructures
: [elf:NAME_ROMANIZED_VARIATION]
: [elf:PLACE_ROMANIZED_VARIATION]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 30 characters.
Identifies the romanization scheme used in the superstructure.
Known values include {`pinyin`, `romanji`, `wadegiles`}.
Default tag
: TYPE
Supertype
: [elf:IndividualAttribute]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 248 characters.
An educational degree or attainment.
Default tag
: EDUC
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 7 characters.
The sex of the individual.
Known values and their meanings are listed in the following table:
Known value Sex
------------- ------------------------------------------------------------
F female
M male
U not knowable from available records
{.note} GEDCOM was silent on if this was to be interpreted as biological sex or gender identity, and it is likely that data exists with both intended meanings.
{.ednote} A revision of or extension to this structure has been discussed by FHISO and is anticipated in a future release of this standard.
Default tag
: SEX
Supertype
: [elf:IndividualAttribute]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 11 characters.
A variant of `[elf:NATIONAL_ID_NUMBER]` assigned by the United States of America.
Default tag
: SSN
{.ednote} I have not made this a subtype of IDNO because IDNO has a required TYPE where SSN does not.
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_REPOSITORY_CITATION]
Substructures
: [elf:SOURCE_MEDIA_TYPE] ?
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 120 characters.
An identifier used by the repository to refer to the cited source.
Default tag
: CALN
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_CITATION]
Substructures
: [elf:ENTRY_RECORDING_DATE] ?
: [elf:TEXT_FROM_SOURCE] *
Payload : None
Default tag
: DATA
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
: [elf:FAM_RECORD]
: [elf:Event]
: [elf:ASSOCIATION_STRUCTURE]
: [elf:PersonalName]
Substructures
: [elf:WHERE_WITHIN_SOURCE] ?
: [elf:EVENT_TYPE_CITED_FROM] ?
: [elf:SOURCE_CITATION_DATA] ?
: [elf:TEXT_FROM_SOURCE] *
: [elf:NOTE_STRUCTURE] *
: [elf:MULTIMEDIA_LINK] *
: [elf:CERTAINTY_ASSESSMENT] ?
Payload
: Either a pointer to a [elf:SOURCE_RECORD] or a block string of arbitrary length.
If the payload is a pointer, then the structure *should not* contain any
`[elf:TEXT_FROM_SOURCE]` substructures.
If the payload is a block string, then the structure *should not* contain any
`[elf:WHERE_WITHIN_SOURCE]`, `[elf:EVENT_TYPE_CITED_FROM]`, or `[elf:SOURCE_CITATION_DATA]` substructures.
It is *recommended* that only the pointer payload version be created.
Default tag
: SOUR
{.note} The text-payload version has significantly less internal structure than does the pointer version. Also note that the text-payload and pointer-payload versions may both contain [elf:TEXT_FROM_SOURCE], but while the text-payload version has it as a direct substructure, the pointer-payload version has it both through the pointed-to structure and nested inside its [elf:SOURCE_CITATION_DATA] substructure.
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD]
Substructures : None
Payload : A block string of arbitrary length.
A description of the source defined by the superstructure;
for example,
a periodical article's `elf:SOURCE_DESCRIPTIVE_TITLE` might include the title of the article and the title of the periodical;
a family bible's `elf:SOURCE_DESCRIPTIVE_TITLE` might include a list of past and present owners and the book's dimensions and appearance.
{.note} Although this tag is called a "title", it is not (just) the title of the work in the usual sense of the word.
Default tag
: TITL
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
A short title for this source.
Intended to be used for sorting and filing.
Default tag
: ABBR
Supertype
: [elf:Structure]
Superstructures
: [elf:EVENTS_RECORDED]
Substructure : None
Payload : A comma-separated list. It is RECOMMENDED that implementations support payloads of at least 120 characters.
A list of names of regions, where each element of the list is subsumed within all subsequent elements.
An assertion that all events recorded in this source
would have a `[elf:PLACE_STRUCTURE]` payload ending with this payload.
{.note ...} While similar to the format of a [elf:PLACE_STRUCTURE] payload, this differs in a few key ways:
- it must use the default
[elf:DEFAULT_PLACE_FORMAT]as it has no[elf:PLACE_HIERARCHY]substructure. - it may (and often does) omit the first several elements of the list. Unlike a
[elf:PLACE_STRUCTURE], the omitted parts are not represented by empty strings, but by removal of their entire entry.- a
[elf:PLACE_STRUCTURE]for an unknown location in Nevada would be ", , Nevada, USA" - a
[elf:SOURCE_JURISDICTION_PLACE]the entirety of Nevada "Nevada, USA" {/}
- a
Default tag
: PLAC
Supertype
: [elf:Structure]
Superstructures
: [elf:MULTIMEDIA_FORMAT]
: [elf:SOURCE_CALL_NUMBER]
Substructure : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 15 characters.
The medium of the source.
Known values include {`audio`, `book`, `card`, `electronic`, `fiche`, `film`, `magazine`, `manuscript`, `map`, `newspaper`, `photo`, `tombstone`, `video`}
Default tag
: MEDI
{.ednote} GEDCOM has this singular (0 or 1 per source record) and describes it listing only one creator. Should we change it to multiple, or de-describe it as listing all creators?
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD]
Substructure : None
Payload : A block string of arbitrary length.
The name of the primary creator of the source.
Default tag
: AUTH
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD]
Substructure : None
Payload : A block string of arbitrary length.
Full publication information for the source: when, where, and by whom it was created..
Default tag
: PUBL
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD]
Substructures
: [elf:EVENTS_RECORDED] *
: [elf:RESPONSIBLE_AGENCY] ?
: [elf:NOTE_STRUCTURE] *
Payload : None
Default tag
: DATA
Supertype
: [elf:Record]
Superstructures
: [elf:Document]
Substructures
: [elf:SOURCE_RECORD_DATA] ?
: [elf:SOURCE_ORIGINATOR] ?
: [elf:SOURCE_DESCRIPTIVE_TITLE] ?
: [elf:SOURCE_FILED_BY_ENTRY] ?
: [elf:SOURCE_PUBLICATION_FACTS] *
: [elf:TEXT_FROM_SOURCE] ?
: [elf:SOURCE_REPOSITORY_CITATION] *
: [elf:MULTIMEDIA_LINK] *
Payload : None
Default tag
: SOUR
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD]
Substructures
: [elf:SOURCE_CALL_NUMBER] *
: [elf:NOTE_STRUCTURE] *
Payload
: Either a pointer to a [elf:REPOSITORY_RECORD] or none.
If the payload is none, there *should* be a `[elf:NOTE_STRUCTURE]` describing where the information described by the containing structure can be found.
Default tag
: REPO
Supertype
: [elf:Structure]
Superstructures
: [elf:INDIVIDUAL_RECORD]
Substructures
: [elf:NOTE_STRUCTURE] *
Payload
: A pointer to a [elf:FAM_RECORD]
It *must* be the case that the pointed-to `[elf:FAM_RECORD]` contains a `[elf:ParentPointer]` pointing to the superstructure of this structure.
Default tag
: FAMS
Supertype
: [elf:Structure]
Superstructures
: [elf:SUBMITTER_RECORD]
Substructure : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 60 characters.
The name of the submitter, formatted as it should be displayed.
Default tag
: NAME
{.ednote} GEDCOM limits these to at most one per HEAD, FAM, and INDI. This seems odd; surely a source, note, etc., can also have a submitter, and there can be more than one contributing submitter per record...
Supertype
: [elf:Structure]
Superstructures
: [elf:FAM_RECORD]
: [elf:INDIVIDUAL_RECORD]
: [elf:Metadata]
Payload
: A pointer to an [elf:SUBMITTER_RECORD]
Indicates that the pointed-to `[elf:SUBMITTER_RECORD]` describes a contributor of information to the containing structure,
or the principle contributor of the entire dataset if in `[elf:Metadata]`.
Default tag
: SUBM
{.note ...} A elf:SUBMITTER_RECORD describes an individual engaged in genealogical reserch; an [elf:INDIVIDUAL_RECORD] describes a subject of that research.
Datasets may contain both kind of record describing the same person.
Although never permitted in its normative text, GEDCOM included at least one example
(under the definition of RELATION_IS_DESCRIPTOR)
where a pointer documented to point to an [elf:INDIVIDUAL_RECORD]
pointed to a elf:SUBMITTER_RECORD instead.
Implementations are encouraged to support reading datasets with that behavior,
but should not create them.
{/}
Supertype
: [elf:Record]
: [elf:Agent]
Superstructures
: [elf:Document]
Substructures
: [elf:SUBMITTER_NAME] !
: [elf:MULTIMEDIA_LINK] *
: [elf:LANGUAGE_PREFERENCE] *
: should not contain a [elf:USER_REFERENCE_NUMBER] even though it is an [elf:Record]
Payload : None
Default tag
: SUBM
{.note} GEDCOM permitted a SUBMITTER_REGISTERED_RFN with tag RFN, the value of which needed to be preregistered with Ancestral File, a service that is no longer available. RFN has thus been removed from this specification, making it an extension tag.
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_RECORD]
: [elf:SOURCE_CITATION]
: [elf:SOURCE_CITATION_DATA]
Substructure : None
Payload : A block string of arbitrary length.
An excerpt of contents of the source.
Default tag
: TEXT
Supertype
: [elf:Structure]
Superstructures
: [elf:CHANGE_DATE_DATE]
: [elf:TRANSMISSION_DATE]
Substructures : None
Payload
: A line string in the lexical space of the elf:Time
datatype defined in §5 of [ELF Dates].
Default tag
: TIME
Supertype
: [elf:Structure]
Superstructures
: [elf:Record]
Substructures
: [elf:USER_REFERENCE_TYPE] ?
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 30 characters.
A user-defined identifier (textual or numeric) of this record.
In GEDCOM, the examples suggests this was to allow brief links to another record keeping system, though its non-multi-values character limits that functionality.
Default tag
: REFN
Supertype
: [elf:Structure]
Superstructures
: [elf:USER_REFERENCE_NUMBER]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 40 characters.
A user-defined definition of the superstructure.
Default tag
: TYPE
Supertype
: [elf:Structure]
Superstructures
: [elf:SOURCE_CITATION]
Substructures : None
Payload : A block string of arbitrary length.
Location information expressing what part of the cited source is being cited.
Default tag
: PAGE
The creation of a legal document regarding the disposition of a person's estate upon death.
Supertype
: [elf:IndividualEvent]
Default tag
: WILL
Supertype
: [elf:Structure]
Superstructures
: [elf:BIRTH]
: [elf:CHRISTENING]
Payload
: A pointer to a [elf:FAM_RECORD].
The pointed-to record describes the family unit associated with the individual event described by the superstructure.
Default tag
: FAMC
The following concrete types are presented in alphabetical order. Data types are presented in the previous section.
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
Contains a copyright statement for the entire dataset.
Default tag
: COPR
Supertype
: [elf:Structure]
Superstructures
: [elf:NAME_OF_SOURCE_DATA]
Substructures : None
Payload : A block string of arbitrary length.
Contains a copyright statement for the source dataset described by the superstructure.
Default tag
: COPR
Contains the default [elf:PLACE_HIERARCHY] for the full document stream.
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures
: [elf:PLACE_HIERARCHY] ?
Payload : None
Default tag
: PLAC
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures
: [elf:VERSION_NUMBER]
: [elf:NAME_OF_PRODUCT]
: [elf:NAME_OF_BUSINESS]
: [elf:NAME_OF_SOURCE_DATA]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 20 characters.
In early GEDCOM, this was a unique string assigned to each product through a registration process.
That process no longer exists.
{.ednote} Do we want to make a new recommendation for the contents of this payload? Perhaps an IRI + date pair? A UUID? A generic "UNREGISTERED_PRODUCT" string or the like?
Default tag
: SOUR
{.ednote} What is the purpose of this structure? Clearly it cannot always match the name of the physical file, which can be renamed without editing; nor are there any limitations given on it in GEDCOM besides that it include an extension if the file containing it has an extension in its name. Without knowing its purpose, I don't know how to document this structure.
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The base name (i.e., not a full path) of a file.
Default tag
: FILE
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures : None
Payload : A block string of arbitrary length.
A description of the intended scope of the contents of the dataset.
Default tag
: NOTE
A holder for formatting and version information.
Supertype
: [elf:Structure]
Superstructures
: [elf:GEDCOM_FORMAT]
Substructures : None
Payload
: The exact string LINEAGE-LINKED
Default tag
: FORM
A holder for formatting and version information.
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures
: [elf:GEDCOM_FORM]
: [elf:VERSION_NUMBER]
Payload : None
Default tag
: GEDC
{.ednote} Should this really be a pseudo-structure? If we re-work this as having language-tagged strings as payloads, then it is; but if we leave the strings in this document as non-language-tagged then it is data instead.
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures : None
Payload : A line string matching the Language Tag microformat.
Indicates the default language of the free-text payloads in the dataset.
Default tag
: LANG
Supertype
: [elf:Agent]
Superstructures
: [elf:DOCUMENT_SOURCE]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The name of the entity that produced the product described by the superstructure.
Default tag
: CORP
Supertype
: [elf:Structure]
Superstructures
: [elf:DOCUMENT_SOURCE]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The name of the product described by the superstructure.
Default tag
: NAME
Supertype
: [elf:Structure]
Superstructures
: [elf:DOCUMENT_SOURCE]
Substructures
: [elf:PUBLICATION_DATE]
: [elf:COPYRIGHT_SOURCE_DATA]
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 90 characters.
The name of an electronic data source from which this dataset was extracted.
Default tag
: DATA
Supertype
: [elf:Structure]
Superstructures
: [elf:NAME_OF_SOURCE_DATA]
Substructures : None
Payload
: A line string in the lexical space of the elf:DateExact
datatype defined in §4.1.1 of [ELF Dates].
Contains the date the source dataset (described by the superstructure) was published or created.
Default tag
: DATE
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructures : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 20 characters.
Identifies the intended recipient software of this dataset.
Default tag
: DEST
Used both in metadata and in data; see [elf:SUBMITTER_POINTER] for a discussion.
Supertype
: [elf:Structure]
Superstructures
: [elf:Metadata]
Substructure
: [elf:TIME_VALUE]
Payload
: A line string in the lexical space of the elf:DateExact
datatype defined in §4.1.1 of [ELF Dates].
The date that this dataset was created.
Default tag
: DATE
Supertype
: [elf:Structure]
Superstructures
: [elf:DOCUMENT_SOURCE]
: [elf:GEDCOM_FORMAT]
Substructure : None
Payload : A line string. It is RECOMMENDED that implementations support payloads of at least 15 characters.
A version identifier, with syntax and semantics varying by context.
If the superstructure is `[elf:GEDCOM_FORMAT]`, the payload *should* be the exact string "`5.5.1`".
Default tag
: VERS
Not a structure at all, elf:Document is a special IRI used as the structure type identifier of the superstructure of a structure that does not have a superstructure but instead is directly included in the dataset.
Not a structure at all, elf:Metadata is a special IRI used as the structure type identifier of the superstructure of a structure that does not have a superstructure but instead is directly included in the metadata of the dataset.
There are several reasons why a structure may be considered an unknown extension to this data model:
-
It is not the first substructure of its type in its superstructure, and the superstructure expected no more than one substructure of its type.
-
It is a substructure of a type not expected by its superstructure.
-
It is missing a required substructure, or that substructure has some error that makes it an extension.
-
Its payload is not appropriate for its structure type: it has a payload where none was expected, or a string where a pointer was expected or vice versa, or a pointer to the wrong structure type or to an extension.
-
Its structure type identifier does not indicate any known structure type.
Unknown extensions are permitted by this data model, and a dataset MUST NOT be rejected simply because it contains unknown extensions. A conformant application MAY remove unknown extension structures, but doing so is NOT RECOMMENDED. Implementations SHOULD NOT create, modify, move, or duplicate structures it considers to be unknown extensions.
If a structure is removed as part of removing an unknown extension, all of its substructures and all structures that point to it MUST also be removed, recursively.
{.note} [ELF-Serialisation] converts most serialisation errors
into unknown extensions with a structure type identifier beginning elf:Unknown.
FHISO currently does not intend to define semantics for elf:Unknown-prefixed structure type identifiers
in any future ELF standard.
This data model may be extended by creating new extension types, which are structure types that are not documented in ELF 1.0.0.
Extension types' structure type identifiers SHOULD be an IRI with an authority component owned by the extension author, as documented in [Basic Concepts].
{.example ...} Suppose an implementation not understanding the http://example.com/WEALTH extension type is processing a dataset containing two elf:INDIVIDUAL_RECORDs, one of which has a http://example.com/WEALTH substructure with payload "34K/A".
- The implementation may choose to ignore the
http://example.com/WEALTHor to display it in some default fashion. - If the dataset is modified and exported
- If the
elf:INDIVIDUAL_RECORDwith thathttp://example.com/WEALTHstill exists in the dataset, thehttp://example.com/WEALTHstructure should be preserved, but it may be omitted. - No additional
http://example.com/WEALTHstructure should be created. - The payload of the existing
http://example.com/WEALTHstructure should not have been modified.
- If the
If the implementation discovers the meaning of http://example.com/WEALTH, it is welcome to create and modify http://example.com/WEALTH structures as it sees fit (subject to any constraints specific to that structure type).
{/}
[Basic Concepts] : FHISO (Family History Information Standards Organisation). Basic Concepts for Genealogical Standards. First public draft. (See https://fhiso.org/TR/basic-concepts.)
[ELF Dates]
: FHISO (Family History Information Standards Organisation).
Extended Legacy Format (ELF): Date, Age and Time Microformats.
Exploratory draft.
(See https://fhiso.org/TR/elf-dates.)
[RFC 2119] : IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Scott Bradner, 1997. (See http://tools.ietf.org/html/rfc2119.)
[RFC 3987] : IETF (Internet Engineering Task Force). RFC 3987: Internationalized Resource Identifiers (IRIs). Martin Duerst and Michel Suignard, 2005. (See http://tools.ietf.org/html/rfc3987.)
[RFC 5322] : IETF (Internet Engineering Task Force). RFC 5322: Internet Message Format. P. Resnick, 2008. (See http://tools.ietf.org/html/rfc5322.)
[RFC 7230] : IETF (Internet Engineering Task Force). RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. Roy Fielding and Julian Reschke, eds., 2014. (See http://tools.ietf.org/html/rfc7230.)
[XML] : W3C (World Wide Web Consortium). Extensible Markup Language (XML) 1.1, 2nd edition. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, and John Cowan eds., 2006. W3C Recommendation. (See https://www.w3.org/TR/xml11/.)
[GEDCOM 5.5] : The Church of Jesus Christ of Latter-day Saints. The GEDCOM Standard, release 5.5. 2 Jan 1996, as amended by the errata sheet dated 10 Jan 1996.
[GEDCOM 5.5.1] : The Church of Jesus Christ of Latter-day Saints. The GEDCOM Standard, draft release 5.5.1. 2 Oct 1999.