FAMILY_RECORD :=n @XREF:FAM@ FAM {1:1} g7:record-FAM
+1 RESN <List:Enum> {0:1} g7:RESN
+1 <<FAMILY_ATTRIBUTE_STRUCTURE>> {0:M}
+1 <<FAMILY_EVENT_STRUCTURE>> {0:M}
+1 <<NON_EVENT_STRUCTURE>> {0:M}
+1 HUSB @<XREF:INDI>@ {0:1} g7:FAM-HUSB
+2 PHRASE <Text> {0:1} g7:PHRASE
+1 WIFE @<XREF:INDI>@ {0:1} g7:FAM-WIFE
+2 PHRASE <Text> {0:1} g7:PHRASE
+1 CHIL @<XREF:INDI>@ {0:M} g7:CHIL
+2 PHRASE <Text> {0:1} g7:PHRASE
+1 <<ASSOCIATION_STRUCTURE>> {0:M}
+1 SUBM @<XREF:SUBM>@ {0:M} g7:SUBM
+1 <<LDS_SPOUSE_SEALING>> {0:M}
+1 <<IDENTIFIER_STRUCTURE>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}
+1 <<CHANGE_DATE>> {0:1}
+1 <<CREATION_DATE>> {0:1}The FAM record was originally structured to represent families where a male HUSB (husband or father) and female WIFE (wife or mother) produce CHIL (children). The FAM record may also be used for cultural parallels to this, including nuclear families, marriage, cohabitation, fostering, adoption, and so on, regardless of the gender of the partners. Sex, gender, titles, and roles of partners should not be inferred based on the partner that the HUSB or WIFE structure points to.
The individuals pointed to by the HUSB and WIFE are collectively referred to as “partners”, “parents” or “spouses”.
Some displays may be unable to display more than 2 partners. Displays may use HUSB and WIFE as layout hints, for example, by consistently displaying the HUSB on the same side of the WIFE in a tree view. Family structures with more than 2 partners may either use several FAM records or use ASSOCIATION_STRUCTUREs to indicate additional partners. ASSO should not be used for relationships that can be expressed using HUSB, WIFE, or CHIL instead.
The FAM record will be revised in a future version to more fully express the diversity of human family relationships.
The order of the CHIL (children) pointers within a FAM (family) structure should be chronological by birth; this is an exception to the usual “most preferred value first” rule. A CHIL with a voidPtr indicates a placeholder for an unknown child in this birth order.
If a FAM record uses HUSB or WIFE to point to an INDI record, the INDI record must use FAMS to point to the FAM record. If a FAM record uses CHIL to point to an INDI record, the INDI record must use a FAMC to point to the FAM record.
An INDI record should not have multiple FAMS substructures pointing to the same FAM.
A FAM record should not have multiple CHIL substructures pointing to the same INDI; doing so implies a nonsensical birth order. An INDI record may have multiple FAMC substructures pointing to the same FAM, but doing so is not recommended.
Source citations and notes related to the start of a specific child relationship should be placed under the child’s BIRT, CHR, or ADOP event, rather than under the FAM record.
INDIVIDUAL_RECORD :=n @XREF:INDI@ INDI {1:1} g7:record-INDI
+1 RESN <List:Enum> {0:1} g7:RESN
+1 <<PERSONAL_NAME_STRUCTURE>> {0:M}
+1 SEX <Enum> {0:1} g7:SEX
+1 <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> {0:M}
+1 <<INDIVIDUAL_EVENT_STRUCTURE>> {0:M}
+1 <<NON_EVENT_STRUCTURE>> {0:M}
+1 <<LDS_INDIVIDUAL_ORDINANCE>> {0:M}
+1 FAMC @<XREF:FAM>@ {0:M} g7:INDI-FAMC
+2 PEDI <Enum> {0:1} g7:PEDI
+3 PHRASE <Text> {0:1} g7:PHRASE
+2 STAT <Enum> {0:1} g7:FAMC-STAT
+3 PHRASE <Text> {0:1} g7:PHRASE
+2 <<NOTE_STRUCTURE>> {0:M}
+1 FAMS @<XREF:FAM>@ {0:M} g7:FAMS
+2 <<NOTE_STRUCTURE>> {0:M}
+1 SUBM @<XREF:SUBM>@ {0:M} g7:SUBM
+1 <<ASSOCIATION_STRUCTURE>> {0:M}
+1 ALIA @<XREF:INDI>@ {0:M} g7:ALIA
+2 PHRASE <Text> {0:1} g7:PHRASE
+1 ANCI @<XREF:SUBM>@ {0:M} g7:ANCI
+1 DESI @<XREF:SUBM>@ {0:M} g7:DESI
+1 <<IDENTIFIER_STRUCTURE>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}
+1 <<CHANGE_DATE>> {0:1}
+1 <<CREATION_DATE>> {0:1}The individual record is a compilation of facts or hypothesized facts about an individual. These facts may come from multiple sources. Source citations and notes allow documentation of the source where each of the facts were discovered.
A single individual may have facts distributed across multiple individual records, connected by ALIA (alias, in the computing sense not the pseudonym sense) pointers. See ALIA for more details.
Individual records are linked to Family records by use of bi-directional pointers. Details about those links are stored as substructures of the pointers in the individual record. Source citations and notes related to the start of the individual’s relationship to parents should be placed under the individual’s BIRT, CHR, or ADOP event, rather than directly under the INDI record, since the former permits explicitly identifying the family record whereas the latter does not.
Other associations or relationships are represented by the ASSO (association) tag. The person’s relation or associate is the person being pointed to. The association or relationship is stated by the value on the subordinate ROLE line. ASSO should not be used for relationships that can be expressed using FAMS or FAMC instead.
The following example refers to 2 individuals, @I1@ and @I2@, where @I2@ is a godparent of @I1@:
Events stored as facts within an INDI record may also have FAMC or ASSO tags to indicate families and individuals that participated in those events. For example, a FAMC pointer subordinate to an adoption event indicates a relationship to family by adoption; biological parents can be shown by a FAMC pointer subordinate to the birth event; the eulogist at a funeral can be shown by an ASSO pointer subordinate to the burial event; and so on. A subordinate FAMC pointer is allowed to refer to a family where the individual does not appear as a child.
MULTIMEDIA_RECORD :=n @XREF:OBJE@ OBJE {1:1} g7:record-OBJE
+1 RESN <List:Enum> {0:1} g7:RESN
+1 FILE <FilePath> {1:M} g7:FILE
+2 FORM <MediaType> {1:1} g7:FORM
+3 MEDI <Enum> {0:1} g7:MEDI
+4 PHRASE <Text> {0:1} g7:PHRASE
+2 TITL <Text> {0:1} g7:TITL
+2 TRAN <FilePath> {0:M} g7:FILE-TRAN
+3 FORM <MediaType> {1:1} g7:FORM
+1 <<IDENTIFIER_STRUCTURE>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<CHANGE_DATE>> {0:1}
+1 <<CREATION_DATE>> {0:1}The multimedia record refers to 1 or more external digital files, and may provide some additional information about the files and the media they encode.
The file reference can occur more than once to group multiple files together. Grouped files should each pertain to the same context. For example, a sound clip and a photo both of the same event might be grouped in a single OBJE.
The change and creation dates should be for the OBJE record itself, not the underlying files.
REPOSITORY_RECORD :=n @XREF:REPO@ REPO {1:1} g7:record-REPO
+1 NAME <Text> {1:1} g7:NAME
+1 <<ADDRESS_STRUCTURE>> {0:1}
+1 PHON <Special> {0:M} g7:PHON
+1 EMAIL <Special> {0:M} g7:EMAIL
+1 FAX <Special> {0:M} g7:FAX
+1 WWW <Special> {0:M} g7:WWW
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<IDENTIFIER_STRUCTURE>> {0:M}
+1 <<CHANGE_DATE>> {0:1}
+1 <<CREATION_DATE>> {0:1}The repository record provides information about an institution or person that has a collection of sources. Informal repositories include the owner of an unpublished work or of a rare published source, or a keeper of personal collections. An example would be the owner of a family Bible containing unpublished family genealogical entries.
Layered repositories, such as an archive containing copies of a subset of records from another archive or archives that have moved or been bought by other archives, are not modeled in this version of the specification. It is expected they will be added in a later version. Until such time, it is recommended that the repository record store current contact information, if known.
SHARED_NOTE_RECORD :=n @XREF:SNOTE@ SNOTE <Text> {1:1} g7:record-SNOTE
+1 MIME <MediaType> {0:1} g7:MIME
+1 LANG <Language> {0:1} g7:LANG
+1 TRAN <Text> {0:M} g7:NOTE-TRAN
+2 MIME <MediaType> {0:1} g7:MIME
+2 LANG <Language> {0:1} g7:LANG
+1 <<SOURCE_CITATION>> {0:M}
+1 <<IDENTIFIER_STRUCTURE>> {0:M}
+1 <<CHANGE_DATE>> {0:1}
+1 <<CREATION_DATE>> {0:1}A catch-all location for information that does not fully fit within other structures. It may include research notes, additional context, alternative interpretations, reasoning, and so forth.
A shared note record may be pointed to by multiple other structures. Shared notes should only be used if editing the note in one place should edit it in all other places or if the note itself requires an IDENTIFIER_STRUCTURE. If each instance of the note may be edited separately and no identifier is needed, a NOTE should be used instead.
Each SNOTE.TRAN must have either a MIME or LANG substructure or both.
The origin of a name might be a reasonable shared note, while the reason a particular person was given that name may make more sense as a non-shared note.
The ability to have multiple structures share a single note using pointers was introduced in version 5.0 in 1991. However, as of 2021 relatively few applications have a user interface that presents shared notes as such to users. It is recommended that SNOTE be avoided when NOTE will suffice.
A SHARED_NOTE_RECORD may contain a pointer to a SOURCE_RECORD and vice versa. Applications must not create datasets where these mutual pointers form a cycle. Applications should also ensure they can handle invalid files with such cycles in a safe manner.
SOURCE_RECORD :=n @XREF:SOUR@ SOUR {1:1} g7:record-SOUR
+1 DATA {0:1} g7:DATA
+2 EVEN <List:Enum> {0:M} g7:DATA-EVEN
+3 DATE <DatePeriod> {0:1} g7:DATA-EVEN-DATE
+4 PHRASE <Text> {0:1} g7:PHRASE
+3 <<PLACE_STRUCTURE>> {0:1}
+2 AGNC <Text> {0:1} g7:AGNC
+2 <<NOTE_STRUCTURE>> {0:M}
+1 AUTH <Text> {0:1} g7:AUTH
+1 TITL <Text> {0:1} g7:TITL
+1 ABBR <Text> {0:1} g7:ABBR
+1 PUBL <Text> {0:1} g7:PUBL
+1 TEXT <Text> {0:1} g7:TEXT
+2 MIME <MediaType> {0:1} g7:MIME
+2 LANG <Language> {0:1} g7:LANG
+1 <<SOURCE_REPOSITORY_CITATION>> {0:M}
+1 <<IDENTIFIER_STRUCTURE>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}
+1 <<CHANGE_DATE>> {0:1}
+1 <<CREATION_DATE>> {0:1}A source record describes an entire source. A source may also point to REPOs to describe repositories or archives where the source document may be found. The part of a source relevant to a specific fact, such as a specific page or entry, is indicated in a SOURCE_CITATION that points to the source record.
This sourcing model is known to be insufficient for some use cases and may be refined in a future version of this specification.
A SOURCE_RECORD may contain a pointer to a SHARED_NOTE_RECORD and vice versa. Applications must not create datasets where these mutual pointers form a cycle. Applications should also ensure they can handle invalid files with such cycles in a safe manner.
SUBMITTER_RECORD :=n @XREF:SUBM@ SUBM {1:1} g7:record-SUBM
+1 NAME <Text> {1:1} g7:NAME
+1 <<ADDRESS_STRUCTURE>> {0:1}
+1 PHON <Special> {0:M} g7:PHON
+1 EMAIL <Special> {0:M} g7:EMAIL
+1 FAX <Special> {0:M} g7:FAX
+1 WWW <Special> {0:M} g7:WWW
+1 <<MULTIMEDIA_LINK>> {0:M}
+1 LANG <Language> {0:M} g7:SUBM-LANG
+1 <<IDENTIFIER_STRUCTURE>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<CHANGE_DATE>> {0:1}
+1 <<CREATION_DATE>> {0:1}The submitter record identifies an individual or organization that contributed information contained in the dataset. All records in the document are assumed to be contributed by the submitter referenced in the HEAD, unless a SUBM structure inside a specific record points at a different submitter record.