WPCc 2BVWZ #|Sold)r5ddd,d `J;HP LaserJet IIISiHPLASIII.PRSd `J;H!\2%C ZS v#|SHP LaserJet IIISiHPLASIII.PRSx  @H!\@(a8DocumentgDocument Style StyleXX` `  ` 2BpWkk2a4DocumentgDocument Style Style . a6DocumentgDocument Style Style GX  a5DocumentgDocument Style Style }X(# a2DocumentgDocument Style Style<o   ?  A.  2vtt^ a7DocumentgDocument Style StyleyXX` ` (#` BibliogrphyBibliography:X (# a1Right ParRight-Aligned Paragraph Numbers:`S@ I.  X(# a2Right ParRight-Aligned Paragraph Numbers C @` A. ` ` (#` 2  t   a3DocumentgDocument Style Style B b  ?  1.  a3Right ParRight-Aligned Paragraph Numbers L! ` ` @P 1. ` `  (# a4Right ParRight-Aligned Paragraph Numbers Uj` `  @ a. ` (# a5Right ParRight-Aligned Paragraph Numbers _o` `  @h(1)  hh#(#h 2   ^ 7 a6Right ParRight-Aligned Paragraph Numbersh` `  hh#@$(a) hh#((# a7Right ParRight-Aligned Paragraph NumberspfJ` `  hh#(@*i) (h-(# a8Right ParRight-Aligned Paragraph NumbersyW"3!` `  hh#(-@p/a) -pp2(#p a1DocumentgDocument Style StyleXqq   l ^) I. ׃  2n+5 ``Doc InitInitialize Document Style  0*0*  I. A. 1. a.(1)(a) i) a) I. 1. A. a.(1)(a) i) a)DocumentgTech InitInitialize Technical Style. k I. A. 1. a.(1)(a) i) a) 1 .1 .1 .1 .1 .1 .1 .1 Technicala5TechnicalTechnical Document Style)WD (1) . a6TechnicalTechnical Document Style)D (a) . 2]Na2TechnicalTechnical Document Style<6  ?  A.   a3TechnicalTechnical Document Style9Wg  2  1.   a4TechnicalTechnical Document Style8bv{ 2  a.   a1TechnicalTechnical Document StyleF!<  ?  I.   2sa7TechnicalTechnical Document Style(@D i) . a8TechnicalTechnical Document Style(D a) . PleadingHeader for numbered pleading paperP@n   $] X X` hp x (#%'0*,.8135@8:> C> "> +> 4"`H2 : ^co(ooo(ooooooM(M(o.;ooooo]]]{]Mo](o]o]o]o]]]](;ooooWMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNo%((u(uoo(VVMMMM(o;u"MMMMMMMMM((MMM((MMM+(ooMMMMMM(xoM(MMoMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMooooo].ooooox"`H2 : ^co(ooo(ooooooM(M(;Moooou]o]oM%o]Z]]]]].] yMooooWMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNoE((u(uoo(VVMMMM(o;u"MMMMMMMMM((MMM((MMM+(ooMMMMMM(xoM(MMoMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM"MMMMMMMMMMMMMMoooo];oooox"`H2 : ^wd7ddd!(!(k(!! (!z!!ooo7o!o!!!!!d oooo(!!!!((((!!(!!!(!!!(!!!!!((o$oo((!!d!  ((((z!!WxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxN!!!_ddddhh0!MMdz"!!!!!dddd4d!d!!!!!!!!!!x!d! !!7!!!!!!!!!!!!!!!!M 7!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (!o k( !!! !7!(!!!!(!!!x"`H2 : ^wdMddd! !! 777 z!77! !!!! ooM!,o!!!!!!!    oooo!7777!!!!!!!77!!!!!!!!!    7777777ok7    o?!!77(!!   !!!!!!! WxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxN!!!ddddhh0!MMdz"!!!!!dddd4d!d!!!!!!!!!!x!d! !!7!!!!!!!!!!!!!!!!\ 7!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!    7!o7 z! 7! ! !7! 77!!!7!!!x2iUm> C > G^ Q"Sh5^;C]ddCCCdCCCCddddddddddCCȲY~~wCN~sk~CCCddCYdYdYCdd88d8ddddJN8ddddYYdYddddddCddddddddd8YYYYYY~Y~Y~Y~YC8C8C8C8ddddddddddYdddddsdddddddd~d~d~d~ddddddddd8ddddoddd~d~d~8~8vddddddkNkdkd~d~d~ddddddYCddCCCWxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNdddCYQQddddddFddddFCChhd44ddzzdddwooChdF"Ȑdhd岲dCCȐzȲxCddodȐȅdCdYdsȐ]ȐȐȧzȐUwŐdȐYYCCCCŐz~ozoY~NYdYC8YooYdYzsdzdd~YYzozzz~CdzYzzzzCCdddddddzCsdYCx"Sh5^;C]ddCCCdCCCCddddddddddCCȲdzN`zoȐCCCddCdoYoYFdo8Co8odooYNCodddYdddddddddCddddddddo8dddddϐYYYYYN8N8N8N8oddddooooddoddddzoddddddodddddddddood8doddNorddoddN8ooddddoNododdddoooooȐdYCddCCCWxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNdddCdUUddddddFddddFCCssd44ddzzddd~ooCsdF"Ȑdsd岲dCCȐzȲxCddodȐȅdCdYdsȐ`ȐȐȮzȐUwŐdȐddCCCCŐzozoYNYYYN8YooYdYzzdzddYYzozzzNdzYzzzzCCdddddddzCzdYCx"`H2 : ^GPoxxPPPxPPPPxxxxxxxxxxPPkP]PPPxxPkxkxkPxxCCxCxxxxY]CxxxxkkxkxxxxxxPxxxxxxxxxCkkkkkkkkkkPCPCPCPCxxxxxxxxxxkxxxxxxxxxxxxxxxxxxxxxxxxxCxxxxxxxxxCCxxxxxx]xxxxxxxxxxkPxxPPPWxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNxxxPkbbxxxxxxTxxxxTPP||x>>xxxxxP|x!T"x}xxPPxPxxxxPxkxofxkkPPPPk]kxkPCkkxkxxxkkPxkPPxxxxxxxPxkPx?xxx,wx6X@8;X@s4ddd,zd6X@8;@\]oc,Z P7P \oc,0A_ p^7r5ddd,Id `J;L?xxx,^x `B;X\ pw,z P7P"nw,0_ p^7\8wC;,[hXw P7XP 7zC;,0sXz_ p^7X\DPG,{4 P7P BPG,0'_ p^7\s-_5/,_ P7P2 > U ^Rc"`H2 : ^GPoxxPPPxPPPPxxxxxxxxxxPPx]tPPPxxPxkkTxCPCxk]PxxxkxxxxxxxxxPxxxxxxxxCxxxxxkkkkk]C]C]C]CxxxxxxxxxxxxxxxxxxxxxxxxxxCxxx]xxxx]Cxxxx]xxxxxxkPxxPPPWxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNxxxPxffxxxxxxTxxxxTPPx>>xxxxxPxT"xxxPPxPxxxxPxkxtfxxxPPPPk]kkk]Ckkxkxxxkk]xkPPxxxxxxxPxkPx"Sh5^/5JPP|555P5555PPPPPPPPPP55Gtenwe_tw5>qewt\tkVewttth555PP5GPGPG5PP,,P,|PPPP;>,PPtPPGGPGPPPPPP5PPPPPPPPP,tGtGtGtGtGknGeGeGeGeG5,5,5,5,wPtPtPtPtPwPwPwPwPtPtGwPtPtPtPwP\PtPtPtPnPnPnPwPePePePePtPtPtPtPtPwPwPP,PPPPuYPPqPePePe,e,_wPwPtPtPtkPkPV>VPVPePePePwPwPwPwPttPhG5PP555WxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxNtttPPP5GAAPPPPPP8PPPP855SSP))PPbbyPPtP_YY5SP8"ttPtSttP厎P55tbttttttttttx5PtPYPtkP5PtGP\t|httttttttttJttttttkb|tD_tttttttPtttttttGttttGttttttttttttttttttttttttttttttttttttttttttt5ttt5ttt5ttt5ttttttttttttttbeYbYkGe>hGwPtG5,qGkYYwGkPtGtb\PbPPeGtGkbtY|bbbtew5PtttbGbbbb55PPPPtwPPPtttb5\PG5x 3'3'Standard3'3'StandardHPLASIII.PRSx  ( #Xw P7[hXP#   Xh   "  4 THE GEDCOM STANDARD ă  Y 5 DRAFT Release 5.3  YY  6 4 November 1993 ă ^6Prepared by the y1Family History Department ) &The Church of Jesus Christ of Latterday Saints  `   c  Suggestions and Correspondence:  GEDCOM Coordinator 3T Family History Department 50 East North Temple Salt Lake City, UT 84150 USA Telephone (USA) 8012404534 2405225  ` X   X"Copyright  1987,1989,1992,1993 by Corporation of the President of The Church of Jesus Christ of Latterday Saints. This document may be copied for purposes of review or programming of genealogical software, provided this  sNA+ notice is included. All other rights reserved."ƀ%A+///XX  Y   9 TABLE OF CONTENTS ă X` hp x (#%'0*,.8135@8:>. Primitive element patterns are enclosed in single angle . The definition of each structure consists of the structure name, a separator (:=), and the structure's component pattern. This pattern consists of (a) GEDCOMlines composed of primitive elements, and/or (b) substructures. Some primitive elements consist of two or more alternative subpattern choices. These choices are shown by listing the alternative subpatterns between opening and closing square [brackets] and separating each choice with a vertical bar (|), meaning that exactly one of the alternate substitutions must be selected. Some definitions of primitive elements use the definition of other primitive elements to complete their definition. This is shown by including the name of the detailed element type inside angle in the definition. The number of subpattern occurrences allowed within a pattern is defined in an occurrence definition in curly {braces} on each line. This number indicates the minimum and maximum number of occurrences allowed for a pattern component in the form {minimum:maximum}. Note that minimum and maximum occurrence limits are defined relative to the enclosing superior line. This means that a required line (minimum = 1) is not required in an instance where the optional enclosing line is not given. Similarly, a line occurring only once (maximum = 1) may occur multiple times as long as each occurs only once under its own multipleoccurring superior line. The level numbers for any substructure are represented as (n), (+1), (+2), and so forth, so that they may be used in more than one place at different starting level numbers. In these cases, (n)P,/..XX equals the level number where the pattern first appears, and the (+1) means one level greater than level n, (+2) means two levels greater than level n, and so forth.    Unless stated otherwise, the only ordering imposed on GEDCOMlines within an enclosure arises when multiple opinions or other items are presented for which only one may be expected by a receiving system. For example, a person may have been known by more than one name, or evidence may suggest a birth either in 1840 in New York or in 1837 in Pennsylvania. In these cases, the most credible or preferred information is listed first, followed by less credible or less preferred items. The QUAY tag may also be used to show the preferred data (see appendix A). Systems that support only a single field within a context should use the first item in the list. Conflicting dates or places of an event should be represented in separate event structures to provide a place for the accompanying source citations, rather than place multiple dates or multiple places under the same enclosing event. Even though no other ordering is defined beyond the one described above, some GEDCOM programming tools optimize performance based on the assumption that tags generally appear in a typical order. Therefore, sending systems are encouraged to present GEDCOM structures in the same general order as the one given in these patterns, unless there is a reason to use a different sequence. This form uses the tag TYPE as a subordinate tag to names, places, events, etc. The intent of this tag is meant to further define its superior tag for the viewer only, it is not intended to inform a computer program how to process the data. The difference between this value and a note value would be that displaying systems should always display the type value when they display the associated data. Therefore, cautious consideration should be used in using the TYPE tag.  c  RECORD STRUCTURES OF THE LINEAGELINKED FORM  ` hp x (#%'0*,.8135@8:>X{1:1} 0<>X{0:M} 0 TRLR X{1:1} There are specific subordinate GEDCOMlines that may be used as subordinate GEDCOMlines to other superior GEDCOMlines. For example:ƀ% 1 BIRT 2 DATE 02 Oct 1937 3 QUAY 1 In the above example QUAY at level 3 indicates how reliable or correct the birth date value is. The QUAY tag applies to any tag that contains a value. This tag is not shown in any of  Y) the structures but the reader and writer of GEDCOM should expect that the QUAY tag  X* could be present as a subordinate tag to any tag that has an associated value. ƀ%  Y+  HEADER: = The header structure provides information about the entire transmission. The SOURce system,/..XX name identifies which system sent the data. The DESTination system name identifies the receiving system. Submission to the Family History Department for Ancestral File is  Y  ANSTFILE. For LDS temple submissions it is TempleReady .ƀ%  Y n HEAD  X{1:1} +1 SOUR X{1:1} +2 VERS X{1:1} +2 NAME X{0:1} +2 CORP X{0:1}  +3 <>X{0:1} +2 DATA X{0:1}  +3 DATE X{0:1} +1 DEST X{0:1} +1 DATE X{0:1} +2 TIME X{0:1} +1 SUBM @XREF:SUBM@X{1:1} +1 FILE X{0:M} +1 COPR X{0:1} +2 CONT X{0:M} +1 SCHEMAX{0:1} +2 <>X{1:M} +1 GEDCX{1:1} +2 VERS X{1:1} +2 FORM X{0:1} +1 CHAR X{0:1} +2 VERS X{0:1} +1 LANG X{0:1} +1 PLACX{0:1} +2 FORM X{1:1}  Y9  RECORD: = [ n<>X{0:1} | n<>X{0:1} | n<>X{0:1} | n<>X{0:1} | n<>X{0:1} | n<>X{0:1} | n<>X{1:1} ]  Y+  FAMILY_RECORD: =  Y, n@XREF:FAM@ FAM X{0:1} ,/..XXԌ+1 HUSB @XREF:INDI@X{0:1} +1 WIFE @XREF:INDI@X{0:1} +1 CHIL @XREF:INDI@X{0:M} +1 REFN X{0:M} +1 X{0:M} +2 TYPE X{0:1} +2 DATE X{0:1} +2 <>X{0:1} +1 X{0:M} +2 TYPE X{0:M} +2 DATE X{0:1} +2 <X{0:1} +1 ASSO @XREF:ANY@X{0:M} +2 TYPE X{0:1} +1 NCHI X{0:1} +1 <>X{0:M} +1 <>X{0:1} +1 <>X{0:1} +1 <>X{0:M} +1 <>X{0:M}  Y  INDIVIDUAL_RECORD: = The occurrence of FAMS and FAMC tags show {0:1}, however; when an individual is referenced in a FAMily record as either a spouse or child, then this record must include a corresponding FAMS and/or FAMC tags. The association of one individual to another can be represented by using the ASSO tag in the individual record to point to the record of the associated individual. The relationship or association is shown in the value field of the subordinate TYPE tag.ƀ% n@XREF:INDI@ INDI +1 <>X{1:1} +1 FAMS @XREF:FAM@X{0:M} +1 FAMC @XREF:FAM@X{0:M} +2 <>X{0:M} +1 ASSO @XREF:REC@X{0:M} +2 TYPE X{0:1} +1 <>X{0:M} +1 RFN X{0:M} +1 REFN X{0:M} +1 AFN X{0:1} +1 ALIA @XREF:INDI@X{0:M} +1 ANCI @XREF:SUBM@X{0:M} +1 DESI @XREF:SUBM@X{0:M} +1 <>X{0:1} +1 <>X{0:1} +1 <>X{0:M} +1 <>X{0:M}  Y+  EVENT_RECORD: = This structure represents eventoriented evidence information that is claimed as a basis for a,/..XX submitter's opinion expressed in Lineagelinked INDIVIDUAL and FAMILY records. Event records define an event in terms of a what happened, where and when it happened, and what individuals are mentioned in the record.ƀ% These event records in some cases will be the source for assertions made in compiling lineagelinked data. SOURce pointers to the bibliographic description of where this event information was recorded should be a part of this record. ƀ% Evidence records from historical sources are kept separate from opinion records created by the submitter. The information contained in evidence records is not redundant with respect to the information contained in submitter's opinions, even when names, dates, or places are the same, because the authority for asserting the information is different.ƀ% Roles of an event which pertain to the event itself are placed subordinate to the event tag. Roles of individuals mentioned in the event which are relationship roles such as the "husband's father" is placed subordinate to the role tag of the groom. For example, the minister at a wedding's role would be represented by the 0 EVENtMARRiageOFFIciator structure. The father of the husband would be represented by the 0 EVENtMARRiageHUSBandFATHer structure. ƀ%  YK n@XREF:EVEN@ EVEN +1 <>X{0:M}  Y  +1 X{1:1} +2 TYPE X{0:1} +2 DATE X{0:1} +2 <>X{0:1} +2 PERI X{0:M} +2 RELI X{0:1} +2 <>X{0:M} +2 <>X{0:1} +2 <>X{0:M} +2 <>X{0:M} +2 X{0:M}  +3 TYPE X{0:1}  +3 <>X{0:1}  +3 ASSO @XREF:INDI@X{0:M}   +4 TYPE X{1:1}  +3 [NULL | @XREF:INDI@ ] {0:M}   +4 TYPE X{0:1}   +4 <>X{0:1}  Yi$  NOTE_RECORD: = /* must contain cross reference ID */ n<>X{1:1} +1 <>X{0:M}  Y(  REPOSITORY_RECORD: = /* must contain cross reference ID */ n<>X{1:1} +1 <>X{0:M}  Y+  SOURCE_RECORD: = /* must contain cross reference ID */ n<>X{1:1},/..XXԌ+1 <>X{0:M}  Y  SUBMITTER_RECORD: = The submitter record identifies individuals or organizations that contributed the opinion information contained within the GEDCOM transmission. All records in the transmission are assumed to be submitted by the SUBMITTER referenced in the HEADer, unless a SUBMitter reference inside a specific record points at a different SUBMITTER.ƀ%  Y2 n@XREF:SUBM@ SUBM X{1:1} +1 <>X{1:1} +1 <>X{0:1} +1 LANG X{0:3} +1 <>X{0:M}  c  SUBSTRUCTURES OF THE LINEAGELINKED FORM  Y  ADDRESS_STRUCTURE: = nSITE X{0:1}  Y_  nADDR X{0:1} +1 CONT X{0:M} +1 PHON X{0:3}  Y BURIAL_STRUCTURE: = Used only when cemetery information is managed separately from the burial place name. It is permissible to include the cemetery name as the low level locality name; for example, Richmond Cemetery, Richmond, Cache, Utah, USA.ƀ% nCEME X{0:1} +1 PLOT X{0:1}  Yc  CHANGE_DATE: =  YM n CHAN  X{1:1} +1 DATE X{1:1} +2 TIME X{0:1} +1 <>X{0:1}  Y!  CHILD_FAMILY_EVENT: = [  Y# n ADOP  X{1:1} +1 TYPE X{0:1} +1 AGE X{0:1} +1 DATE X{0:1} +1 <>X{0:1} +1 <>X{0:1} +1 <>X{0:1} | n<>X{0:1} ] ,/..XXԌ Y  CORRECTNESS_ASSESMENT: =  Y n QUAY X{0:1} /* used subordinate to any tag containing a value */  Y  EVENT_STRUCTURE: = Information about an individual with respect to a specific event, such as the age, marital status, religious affiliation of this individual at time of this event. Keep in mind that this is data specific to the individual owning this event and not the data that belongs to the source in which this data was found. For instance Immigration and Emigration events should use a reference a source structure to show the SHIP and PORT information concerning the event. Roles of other individuals can be shown using the EVENt record. A link to the event record can be made by using the SOURce structure to point to the EVENt record. The event record in this case would be an evidence record supporting the assertions made in creating this event structure.ƀ%  Y n < EVENT_TAG > X{1:1} +1 TYPE X{0:M} +1 DATE X{0:1} +1 <>X{0:1} +2 <>X{0:1} +1 AGE X{0:1} +1 MSTAT X{0:1} +1 CAUS X{0:1} +1 RELI X{0:1} +1 AGNC X{0:1} +1 <>X{0:1} +1 <>X{0:1} +1 <>X{0:1} +1 <>X{0:M}  YR  INDIVIDUAL: = n<>X{1:M} nTITL X{0:M} nSEX X{0:1} n<>X{0:M} n<>X{0:M} nRELI X{0:M} nNAMR X{0:M} +1 RELI X{0:1} nEDUC X{0:M} nOCCU X{0:M} nSSN X{0:M} nIDNO X{0:M} +1 TYPE X{1:1} nPROP X{0:M} nDSCR X{0:M} +1 CONT X{0:M} nSIGN X{0:M} nNMR X{0:M} nNCHI X{0:M} ,/..XXԌnNATI X{0:M} nCAST X{0:M}  Y  LDS_CHILD_SEALING_EVENT: =  Y n SLGC  X{1:1} +1 TYPE X{0:1} +1 DATE X{0:1} +1 TEMP X{0:1}  Y3  LDS_FAM_ORDINANCE_EVENT: =  Y n SLGS  X{1:1} +1 TYPE X{0:1} +1 DATE X{0:1} +1 TEMP X{0:1}  Y  LDS_INDI_ORDINANCE_EVENT: = n X{1:1} +1 TYPE X{0:1} +1 DATE X{0:1} +1 TEMP X{0:1} +1 <>X{0:1} +1 <>X{0:1}  Y  MULTI_MEDIA_LINK: = nAUDIO X{0:1} nPHOTO X{0:1} nVIDEO X{0:1}  Y  NAME_STRUCTURE: =  Yl n NAME X{1:1} +1 TYPE X{0:1} +1 <>X{0:1} +1 <>X{0:1}  Y  NOTE_STRUCTURE: = This structure contains information originated by the submitter.ƀ%  Y n[ @XREF:NOTE@ | NULL ] NOTE [ | NULL ] {1:1} +1 CONT X{1:M} +1 NOTE @XREF:NOTE@X{0:1}  Yr$  PLACE_STRUCTURE: =  Y\% n PLAC X{1:1} +1 FORM X{0:1} +1 <>X{0:1} +1 <>X{0:1} +1 <>X{0:1}  Y*  REPOSITORY_STRUCTURE: =  Y+ n[ @XREF:REPO@ | NULL ] REPO X{1:1} +2 NAME X{0:1},/..XXԌ+2 CNTC X{0:1} +2 <>X{0:1} +2 MEDI X{0:1} +2 CALN X{0:1}  +3 ITEM X{0:1}  +3 SHEE X{0:1}  +3 PAGE X{0:1} +2 REFN X{0:1} +2 <>X{0:1}  X  SOURCE_STRUCTURE The source structure represents the submitter's basis (justification) for the opinions asserted in a lineage linked transmission. This information is used by other researchers to (1) determine how much confidence to place in the associated assertions, (2) compare new evidence to old evidence from prior research, and (3) locate and examine the evidence to make an independent evaluation of it. If a source is not explicitly cited for a given context, the source is by default ascribed to be the personal opinion of the submitter, with no further basis for its credibility.ƀ% The justification takes the form of a description of the source from which the evidence was obtained, and may include a machinereadable representation of the evidence itself, such as an image of a document or an extract of its contents.ƀ% A given source may be the basis for many different assertions. Thus, much of the information is the same for many different citations of that source, such as the publisher information; and yet, some of the information varies from one citation to the next, such as the page number for a specific item. Consequently, the SOURCE_STRUCTURE includes a sophisticated mechanism for sharing general source description information that is common across multiple citations, while at the same time allowing more specific information to be more directly associated with individual citations. All tags within the SOURCE_STRUCTURE participate in this approach.ƀ% To implement the mechanism, the SOURCE_STRUCTURE includes a SOURce pointer that refers to another SOURCE_STRUCTURE containing more general information to be included in the citation. This forms a chain of records, beginning within an individual or family record and ending in a source record that does not contain another SOURce pointer.ƀ% A given tag may appear in more than one record along the chain. In this case, the tag occurring in one link (source record) of the chain is said to shadow or supersede the same tag found in subsequent records of the chain. A program looking for a particular tag (or tags) in the citation starts looking in the first record of the chain and continues looking in each subsequent record in the chain for the appropriate tag, succeeding when the tag is found or failing when the end of the chain is reached. In effect, a complete logical source citation is the set of all tags of all records within the source chain, excluding shadowed tags.ƀ% The chain may consist of only one SOURCE_STRUCTURE contained entirely inside an individual or family record, with no SOURce pointer leading out from the individual or family record. More typically, the chain will begin in the individual or family record and end in an ordinary source description record. Occasionally, a multiple volume source may be represented using a record in the middle of the chain for specific information about the volume.ƀ%,/..XXԌFor example, in a multiple volume source where each volume covered a range of years, a volume description would contain the PERIod covered by the volume, and the more general description of the set of volumes would contain the PERIod covered by the entire set of volumes. In assembling the complete source citation, the program would stop searching for the PERIod as soon as it found a PERIod tag, which in this case would be in the volume description. In a multiple volume source where each volume covered a specific place as part of a larger grouping of places, the program would find the PLACE_STRUCTURE information in the intermediate volume description, and it would find the PERIod information in the final, more general description of the set of volumes.ƀ% We encourage data entry systems to develop flexible entry screens which will prompt their users for information which will meet the minimum standards for citing sources. At the minimum there should be an entry form for published sources and one for unpublished sources. The elements below are marked if they were recommended by the National Genealogical Society as being a help in citing puplished (p) or unpublished (u) sources.ƀ%  Y  SOURCE_STRUCTURE: = /****** TYPE OF SOURCE ******/  Yc n[ @XREF:SOUR@ | NULL ] SOUR [ | NULL ]  YM +1 [ CONT | CONC ] X{0:1} +1 CLAS X{1:1}up +1 EVEN X{0:1} +1 PERI X{0:M}up /****** CITATION SPECIFIC INFO ******/ +1 TITL [ | @XREF:SOUR@] X{0:1}up +1 SOUR [ @XREF:SOUR@ | @XREF:EVEN ]X{0:M}up +1 PAGE X{0:1}up +1 DATE X{0:1}u +1 CENSX{0:1} +2 DATE X{0:1}u +2 LINE X{0:1}u +2 DWEL X{0:1}u +2 FAMN X{0:1}u +2 <>X{0:1} /****** WHO CREATED IT ******/ +1 ORIG X{0:M} +2 NAME X{0:1}up +2 TYPE X{1:1}up +2 <>X{0:1} /****** PUBLICATION INFO ******/ +1 PUBLX{0:1} +2 TYPE X{1:1}up +2 NAME X{0:1}p +2 PUBR X{0:1}p +2 < X{0:1} +2 DATE X{0:1}up +2 EDTN X{0:1}p +2 SERS X{0:1}p +2 ISSU X{0:1}p,/..XXԌ+2 LCCN X{0:1} /****** WHERE IS IT STORED ******/ +1 <>X{0:1}up /****** IMMIGRATION/EMIGRATION ***/ +2 NAME X{0:1} +2 PORTX{0:1}  +3 ARVLX{0:1}   +4 DATE X{0:1}   +4 PLAC X{0:1}  +3 DPRTX{0:1}   +4 DATE X{0:1}   +4 PLAC X{0:1} +2 <>X{0:1} +2 <>X{0:1} /****** SUPPORT DATA ******/ +1 <>X{0:1} +1 <>X{0:M} +1 <>X{0:1} +1 STAT X{0:1} +2 DATE X{0:1} +1 REFS @XREF:SOUR@ /* REFERENCED SOURCE */X{0:1} +1 FIDE X{0:1} +1 QUAY X{0:1}  Y TEXT_STRUCTURE: = This structure contains information from the source document.ƀ%  Y} n TEXT X{1:1} +1 [ CONT | CONC ] X{1:M} +1 <>X{0:1}  Y"  USER_TAG_IN_CONTEXT: = A context structure which represents all of the superior level numbers and associated tags from level zero to the level of the new user tag. All user tag names must start with and underscore (_).ƀ%  Y! 0 < OLD_TAG_1 > X{1:1} 1 X{0:M} 2 _ X{0:M}   /* always start user tag name with an underscore (_).*/ For example, two new user tags are to be defined as _HOSP and _NURS and placed subordinate to an individual's birth. The user tag in context would be:xx](Example only)ƀ% nINDI +1 BIRT +2 _HOSP +2 _NURS The resulting USER_TAG_SCHEMA, to be included in the HEADer record, would then look,/..XX like the following:ƀ% (Example only) nSCHEMA +1 INDI +2 BIRT  +3 _HOSP   +4 LABL   +4 DEFN   +4 ISA  +3 _NURSE   +4 LABL   +4 DEFN   +4 ISA See User Defined Tag section at the end of chapter 2 for additional information.ƀ%  Y  USER_TAG_SCHEMA: = n<>X{1:M} +m LABL X{1:1} +m DEFN X{1:1} +m ISA X{1:1}   /* +m represents the first subordinate level to the new user defined tag level. (See example shown under the substructure definition for USER_TAG_IN_CONTEXT). */ƀ% /..XX  c  PRIMITIVE ELEMENTS OF THE LINEAGELINKED FORM  X Tx (#%'0*,.8135@8: ƀ% ,A date associated with an arrival event, such as the arrival of a ship into a port.ƀ%  Y  ARRIVAL_PLACE: =~~H{Size=1:120} , ƀ% ,The place from which travel terminated, such as the locality name of a port of arrival, such as Ellis Island, New York, New York.ƀ%  Y{  ASSOCIATION_DESCRIPTOR: =~~H{Size=1:90} ,A word or phrase that describes the association between this person and another person identified by a pointer. (For example, n ASSO great grandfather @XREF:SUBM@ would be read, this person is a greatgrandfather of the person defined in the submitter record.)ƀ%  Y  AUXILLARY_FILE_REFERENCE: =~~H{Size=1:30} ,A full file reference to the auxillary data to be linked to the GEDCOM context.ƀ%  Y"  AUXILLARY_SET_FORMAT: =~~H{Size=1:10} [ OLE | GIF | TIF | WPG | etc. ] ,Indicates the format of the data that is being linked to the GEDCOM context. This will allow the GEDCOM processor to determine whether they are able to process the auxillary data. The auxillary file should contain a header record with data required, by the indicated format, to process the file data.ƀ%  Y%)  CALENDAR_ESCAPE_SEQUENCE: =~~H{Size=4:15} [ @#DHEBREW@ | @#DROMAN@ | @#DFRENCH R@ | @#DGREGORIAN@ |  @#DJULIAN@ | @#DUNKNOWN@ ] ,An escape sequence that allows dates from one of the indicated calendars to be represented. The default calendar is the Gregorian calendar.ƀ%,/..XXԌ Y ԙ CASTE_NAME: = ${Size=1:90} ,A name assigned to a particular group that this person was associated with, such as a particular racial group, religious group, or a group with an inherited status.ƀ%  Y  CAUSE_OF_DEATH: =~~H{Size=1:90} ,The cause of death of this person. This should be the same cause as listed on the death certificate if known. (A medical history structure may be developed for a future GEDCOM release.)ƀ%  Y3  CEMETERY_NAME: =~~H{Size=1:90} ,The name of the cemetery where a person was buried.ƀ%  Y  CHANGE_DATE: =~~H{Size=10:11} ,ƀ% ,The date that this data was last changed.ƀ%  Y  CHARACTER_SET: =~~H{Size=1:8} ,A code value that represents the character set to be used to interpret this data. The default character set is ANSEL which includes ASCII as a subset. UNICODE is also will be allowed. See chapter 3.ƀ%  Y"  CHILD_FAMILY_EVENT_DESCRIPTOR: =~~H{Size=1:90} ,A word or phrase that describes or modifies the adoption event being reported.ƀ%  Y  CONCATENATED_DATA: =~~H{Size=1:247} ,Adds new data to the end of the data in the preceding context.ƀ%  Y  CONTACT_PERSON: =~~H{Size=1:120} ,ƀ% ,The name of the person to whom communications should be addressed.ƀ%  Y?  CONTINUED_DATA: =~~H{Size=1:247} ,A new line which logically is included in the preceding line. This may be used in specified situations where the value length exceeds the maximum allowed length for the line.ƀ%  Y  COPYRIGHT_STATEMENT: =~~H{Size=1:90} ,A copyright statement needed to protect the rights of the owner of this data.ƀ%  Y"  CORPORATE_NAME: =~~H{Size=1:90} ,The company, corporate or government agency name.ƀ%  Y\%  COUNT_OF_CHILDREN: =~~H{Size=1:3, Type=NUMBER} ,The number of children of this individual from all marriages or of this family, regardless of whether the associated children are represented in the GEDCOM file.ƀ%  Y)  COUNT_OF_MARRIAGES: =~~H{Size=1:3, Type=NUMBER} ,The number of different families that this person was known to have been a member of as a spouse or parent, regardless of whether the associated families are represented in the GEDCOM file.ƀ% ,/..XXԌ Y  DATE_DUAL: = ${Size=1:90} , ƀ% ,A date which shows the possible date alternatives arising from a calendar change, for example, 15 Dec 1752/3. ƀ%  Y  DATE_EXACT: = ${Size=10:11} , ƀ% ,A formatted date with one space between the day and the month and one space between the month and the year.ƀ%  Y  DATE_MODIFIER: =~~H{Size=3:15} ,[ ABT | AFT | BEF | EST | ]ƀ% ,Qualifies the meaning of a date.ƀ% ABT = About AFT = After BEF = Before EST = Estimated  Ye  DATE_PHRASE: = ${Size=1:90} ,ƀ% ,Any statement offered as a date when the specific year is not known, but which gives information about when an event occurred. ƀ%  Y  DATE_RANGE: = ${Size=17:31} ,[ BET AND ]ƀ%  Y  DATE_REGULAR: =~~H{Size=4:35} ,[ | | ]ƀ%   YT  DATE_VALUE: = ${Size=1:90}  Y> ,[ | | | |ƀ% | ] Examples: 15 JUN 1990 2 days after easter 1790 BET NOV 1830 AND 25 DEC 1830 600 B.C. ABT 1 JAN 1440 @#DFRENCH R@28 NIVOSE AN09  YB&  DATE_WITH_BC: =~~H{Size=1:90} ,[ B.C. ]ƀ% ,A date of an event that occurred before Christ.ƀ%  Y)  DAY: =  $~~H{Size=1:2, Type=NUMBER} ,ddƀ% ,Day of the month, where dd is a numeric digit whose value is within the valid range of the days for the associated month.ƀ%,/..XXԌ Y ԙ DEPARTURE_DATE: =~~H{Size=1:90} , ƀ% ,A date associated with an departure event, such as the departure of a ship from a port.ƀ%  Y  DEPARTURE_PLACE: =~~H{Size=1:120} , ƀ% ,The place from which travel began, such as the locality name of a port of departure, such as Pier 37, San Francisco, California.ƀ%  Y3  DESCRIPTIVE_TITLE: =~~H{Size=1:247} ,A descriptive title of the information source, such as a description of: ƀ% 0 A title of an article published in a periodical. ƀ% 0 A letter including the date, the sender and the receiver.ƀ% 0 A transaction between a buyer and seller including their names and date of transaction. ƀ% 0 A Family Bible containing genealogical information including past and present owners and a physical description of the book. ƀ% 0 A personal interview. ƀ%  YN  DIVORCE_DESCRIPTOR: =~~H{Size=1:90} ,A word or phrase that commonly describes the kind of separation, such as "divorce" or "separated", that took place between husband and wife. The separation descriptor should use the same word or phrase and in the same language, whenever possible, that was used by the recorder of the event.ƀ%  Y  DIV_EVNT_TAG: =~~H{Size=3:4}  Y [ ANUL | DIV | DIVF ] (See Appendix B for additional Tags) ,A family event tag which describes the event of separation.ƀ%  Yk  ENTRY_RECORDING_DATE: =~~H{Size=1:90} ,ƀ% ,The date that the entry was entered into the source record by the recorder.ƀ%  Y  ESCAPE_TO_AUXILLARY_PROCESSING: =~~H{Size=1:30} [ @#A ,An escape sequence which allows for alternate data formats to be linked to a specific context within the GEDCOM file. The linked data referenced is for special processing and is tied to the context in which the escape was issued. For instance, data specific to Window's Object linking and embedding servers would be referenced in this manner. See Chapter 6, "Microsoft Windows Programmer's Reference" for the format of the standard OLE data stream. This allows the transmission of images, sounds, or other auxillary processing associated with the enclosing context. The format of the escape sequence has only been designed for including data by referencing a specific file name. This means that there will be an unique auxillary data file for each link. In the future we may adopt a method of including all of the auxillary data in a single auxillary transmission file. Other auxillary process formats may also be defined in later GEDCOM versions.ƀ%  Y*  EVENT_CLASSIFICATION_CODE: =~~H{Size=1:90} ,[ | ]ƀ% ,A code that classifies the principal event that caused this source record to be created.ƀ%,/..XXԌ Y ԙ EVENT_DESCRIPTOR: =~~H{Size=1:90}  Y ,A descriptor that should be used whenever the EVEN tag is used to define the event being cited.  Y For example, if the event was a purchase of a residence, the EVEN tag would be followed by the phrase "Purchased Residence." When this descriptor is used with any of the defined event  Y tags, it modifies the basic definition of the associated tag. For example the BIRT tag could be used in connection with an EVENT_DESCRIPTOR of "Stillborn" to modify the birth event as a stillborn birth. An EVENT_DESCRIPTOR of "DEAD" shows a person is dead but the death  Yc date is not known . The event descriptor should use the same word or phrase and in the same language, when possible, that was used by the recorder of the event. Systems that display data from the GEDCOM form should be able to display the descriptor value in their screen or printed output.ƀ%  Y  EVENT_TAG: = ${Size=3:4} [ | | ] ,An event tag chosen from the tags identifying either individual or family events, including the EVEN tag with an event descriptor.ƀ%  Y~  FAMILY_EVENT_DESCRIPTOR: =~~H{Size=1:90} ,A word or phrase that best describes the circumstances that created this family. The marriage descriptor should use the same word or phrase and in the same language, when possible, that was used by the recorder of the event. Possible descriptor values include "Childbirthunmarried," "Common Law," "Tribal Custom," for example. Systems that display data from the GEDCOM form should be able to display the descriptor value in their screen or printed output. (See also .)ƀ%  Y  FAM_EVNT_TAG: =~~H{Size=3:4} [ CENS | MARR | MARB | MARC | MARL | MARS | ENGA | EVEN ]  (See Appendix B for additional Tags) ,An event tag indicating the reason for defining a family.ƀ%  YU  FILE_NAME: = $~~H{Size=1:90} ,The name of the GEDCOM transmission file on the source operating system. It includes the path, file name, and file extension. The path may optionally include the drive letter.ƀ%  Y  FILM_ITEM_IDENTIFICATION: =~~H{Size=1:90} ,A particular book or unit of material that may have been filmed with other books or units on the same microfilm. The convention used in the Family History Department microfilms is to include a separator frame with a sequential item number to separate multiple books on a single film.ƀ%  Yq$  FULL_TAG_NAME: =~~H{Size=1:15} ,The long name of a user defined GEDCOM tag. For example, HOSP tag would have a long name of HOSPITAL. This name should be a name that could be used as a field label for reports and screens. The name may include underscore characters (_).ƀ%  Y(  GEDCOM_FORM: =~~H{Size=1:15} [ LINEAGELINKED | (others to be registered) ] ,The GEDCOM form used to construct this transmission.ƀ%  Y,  GOVERNMENT_AGENCY: =~~H{Size=1:90},/..XXԌ,The name of the branch of government associated with this event or data.ƀ%  Y  IND_EVNT_TAG: =~~H{Size=3:4}  Y [ ADOP | BIRT | BAPM | BARM | BASM | BLES | BURI | CENS | CHR | CHRA |  Y  CONF | DEAT | EVEN | EMIG | GRAD | IMMI | MARR | NATU | ORDN | RETI |  PROB | WILL ]  Yb ,An individual event tag. The EVEN tag must be followed by a TYPE and an . The is optional for the defined event tags, for example: ƀ%  Y  1 EVEN  Y  2 TYPE Farley Family Reunion  Y  1 BIRT  Y  2 TYPE illegitimate ,(See Appendix A for tag definitions or see Appendix B for proposed Tags. These proposed tags  Y have not been standardized. They may be used as a value for the TYPE tag under the EVEN tag or under the appropriate approved event tags. Appropriate means that the event should be processed the same as the selected superior tag)ƀ%  Y=  INDI_TITLE: = $~~H{Size=1:90} ,A formal designation used by an individual in connection with the individuals name, for example, (Captain) John Smith. ƀ%  Y  INFORMANTS_NAME: =~~H{Size=1:90} ,ƀ% ,The name of a person who contributed evidence information.ƀ%  Y  INTERVIEWERS_NAME: =~~H{Size=1:90} ,ƀ% ,The name of the person who conducted the interview for information.ƀ%  Y,  IS_A_KIND_OF_TAG: =~~H{Size=1:25} [ ] ,The human language in which the data in the transmission is normally read or written. It is used primarily by programs to select languagespecific sorting sequences and phonetic name matching algorithms.ƀ%  Y"  LANGUAGE_PREFERENCE: =~~H{Size=1:90} [ ] ,The language in which a person prefers to communicate. Multiple language preference is shown by using multiple occurrences in order of priority.ƀ%  Y1'  LANGUAGE_TABLE: =~~H{Size=1:25} ,A table of valid language codes. This table of valid languages may be found in the Encyclopedia Britannica 1989 Book of the Year.ƀ%  Y* LDS_CHILD_SEALING_DESCRIPTOR: =~~H{Size=1:20}  ,A descriptor that describes the disposition of this ordinance. The appropriate descriptor is one,/..XX of the choices defined by . ƀ%  Y  LDS_FAM_ORD_DESCRIPTOR: =~~H{Size=1:20}  ,A descriptor that describes the disposition of this ordinance. The appropriate descriptor is one of the choices defined by . ƀ%  Y`  LDS_INDI_ORD: = ${Size=3:4} ,[ BAPL | CONL | WAC | ENDL ]ƀ% ,A tag that represents an individual's religious event associated with The Church of Jesus Christ of Latter-day Saints. (See Appendix A for a definition of these tags.)ƀ%  Y  LDS_INDI_ORD_DESCRIPTOR: =~~H{Size=1:90}  ,A descriptor that specifies the disposition of this ordinance. The appropriate descriptor is one of the choices defined by . ƀ%  Y|  LDS_ORDINANCE_DESCRIPTOR: =~~H{Size=1:20} ,[ BIC | CANCELED | COMPLETED | DNS | DONE | INFANT | STILLBORN | SUBMITTED ]ƀ% ,A code indicating the status of an LDS ordinance.ƀ% ,BIC = $This person was born in the covenant, meaning that he or she automatically receives the blessing of 'child to parent' sealing.ƀ% ,COMPLETED= $This ordinances has been completed but the date is not known.ƀ% DNS =" $This record is not being submitted for this temple ordinances.ƀ% DONE =" $This ordinance has been completed but the date is not known.ƀ% INFANT =" $This person died before eight years old.ƀ% STILLBORN =" $This person was stillborn.ƀ% SUBMITTED =" $This ordinance was previously submitted.ƀ%  YR  LIBRARY_CONGRESS_CALL_NUMBER: =~~H{Size=1:20} ,The call number assigned to this item by the U.S. Library of Congress. ƀ%  Y  MANUAL_FILING_IDENTIFICATION: =~~H{Size=1:90} ,A description of where the source is manually filed at this repository or personal collection. Personal genealogical collections should be organized and filed so that items can be specifically identified and retrieved. For example, "Probate file Drawer 83, File D, Number 18", or "Box 3, Smith Folder".ƀ%  Y#  MARITAL_STATUS: =~~H{Size=1:20} ,[ D | S | W | _ ]ƀ% ,The marital status at the time of the associated event. Status values are:ƀ% XD = Single but legally Divorced at time of event.ƀ% M = Married at time of event. S = Single, never married at time of event. W =0 Single because of the death of a spouse.ƀ% ,_ = If other information about marital status is to be shown add the appropriate text preceded by an underscore "_".ƀ%  Y,  MEDIA_TYPE: = ${Size=1:15}, /..XXԌ,[ AUDIO | BOOK | CARD | ELECTRONIC | FICHE | FILM | MAGAZINE | MANUSCRIPT | MAP | NEWSPAPER | PHOTO | TOMBSTONE | VIDEO ]ƀ% ,A code, selected from one of the media classifications choices above that indicates the type of material in which the referenced source is stored.ƀ%  Y  MONTH: =  $~~H{Size=3:3} ,[ JAN | FEB | MAR | APR | MAY | JUN |ƀ%  JUL | AUG | SEP | OCT | NOV | DEC ] ,A month name abbreviation selected from the choices above, used in forming dates.ƀ%  Y  NAME_OF_SOURCE_DATA: =~~H{Size=1:90} ,The name of the electronic data source that was used to obtain the data in this transmission. For example, the data may have been obtained from a CD-ROM disc that was named "U.S. 1880 CENSUS CDROM vol. 13."ƀ%  Y  NAME_OF_VESSEL: =~~H{Size=1:90} ,A name of the ship, air ship, or commercial vehicle used for travel, immigration, emigration, etc.ƀ%  YN  NATIONALITY: = ${Size=1:90} ,The person's national origin in common usage. Examples: Irish, Native American, Swede, and so forth.ƀ%  Y  NATIONAL_ID_NUMBER: =~~H{Size=1:30} ,A nationallycontrolled number assigned to an individual. Commonly known national numbers should be assigned their own tag, such as SSN for U.S. Social Security Number. The use of the IDNO tag requires a subordinate TYPE tag to identify what kind of number is being stored. For example:ƀ% n IDNO 434561899  +1 TYPE Canadian Health Registration  Y<  NEW_TAG: =  ${Size=3:15} ,A user defined tag that is contained in the GEDCOM current transmission. This tag must be defined within the SCHEMA context in the HEADer record and its name must begin with an underscore (_). The SCHEMA context defines the data associated with this new tag. (See tags LABL, DEFN, and ISA).ƀ%  Y!  NULL: =  $~~H{Size=0:0} ,convention that indicates the absence of any characters in the value includingƀ% ,A the null character (0x00) which is prohibited.ƀ%  YX%  OCCUPATION: = $~~H{Size=1:90} ,The kind of activity that an individual does for a job, profession, or principal activity.ƀ%  Y(  OLD_TAG_1: = $~~H{Size=3:15} ,This is any tag defined by the GEDCOM standard and is used in the SCHEMA context of the HEADer record to show the context in which a new user defined tag is being used. This tag always represents a tag which was used at level 0.ƀ%  Y,  OLD_TAG_2: = $~~H{Size=3:15},!/..XXԌ,This is any tag defined by the GEDCOM standard and is used in the SCHEMA context of the HEADer record to show the context in which a new user defined tag is being used. Old_TAG_2 represents any tag at any level between level 1 and the level in which the new user defined tag resides. For example, ƀ% n SCHEMA +1 INDI (zero level) +2 BURI  +3 PLAC  +4 CEME   +5 _PLOT (new user tag)  Y  ORD_BY_PATRON_CODE: =~~H{Size=1:1} [ Y | N ] ,A code that identifies whether the patron will provide proxies for the cleared ordinances specified by the associated tag.ƀ% Y = Patron will provide proxies for the associated cleared ordinance. N = Temple is to provide proxies for the associated cleared ordinance.  Yc  ORIGINATOR_NAME: =~~H{Size=1:120} [ | ] ,The name of the person or organization that created this source.ƀ%  Y  ORIGINATOR_TYPE: =~~H{Size=3:15} [ AUTHOR | COMPILER | TRANSCRIBER | ABSTRACTOR | EDITOR |  INFORMANT | INTERVIEWER | GOVERNMENT | BUSINESS | ORGANIZATION ] ,A classification of the type of the person or entity that created this source.ƀ%  Y  PAGE_DESCRIPTION: =~~H{Size=1:90} ,A field that identifies the page within the source. This may be a page number range, a specific page number, or another way of defining how to find the specified information within the source.ƀ%  Y$  PERIODICAL_ISSUE_NUMBER: =~~H{Size=1:90} ,The number or description of the specific periodical publication.ƀ%  Y  PERMANENT_RECORD_FILE_NUMBER: =~~H{Size=1:18} : ,The record number that uniquely identifies this record within a registered network resource. The number will be usable as a crossreference pointer. The use of the colon (:) is reserved to indicate the separation of the 'registered resource identifier'(precedes the colon) and the unique 'record identifier' within that resource (follows the colon). In cases where the colon is used, implementations that check pointers should not expect to find a matching cross reference identifier in the transmission but would find them in the indicated database within a network. Making resource files available to a public network is a future implementation.ƀ%  Y(  PERSONAL_NAME: =~~H{Size=1:120} ,[ƀ%  | // |  // |,"/..XXԌ// |  // ] ,The surname of an individual, if known, is enclosed between two slash (/) characters. The order of the name parts should be the order that the person would customarily have used when giving it to a recorder. If part of name is illegible, that part is indicated by ... (ellipses).ƀ% Examples: William Lee /Parry/ William Lee /Parry/ William /Lee/ Parry William Lee /Pa.../  Y  PHONE_NUMBER: =~~H{Size=1:25} ,A phone number.ƀ%  Yz  PHYSICAL_DESCRIPTION: =~~H{Size=1:247} ,A comma delimited, unstructured list of the attributes that describe the physical characteristics of a person, place, or object.ƀ% Example: 1 DSCR Hair Brown, Eyes Brown, Height 5 ft 8 in  Y  PLACE_VALUE: = ${Size=1:120} [  | , ] ,The jurisdictional name of the place where the event took place. Jurisdictions are separated by commas, that is, town, county, state or village, parish, country. Receiving systems cannot assume that the nth locality position is necessarily a specific level of jurisdiction. Some systems may include a PLAC context in the HEADer record which will specify the jurisdictional levels to the place names. Missing intermediate jurisdictions is represented by adjacent placeholder commas. If FORM value within the PLACe context of the HEADer record is present, then all levels of jurisdiction must be accounted in this way. For example if the following was included in the header record:ƀ% 0 HEAD  1 PLAC  2 FORM city, county, state, country ,Then each place name would be expected to account for the four levels by using appropriately placed commas.ƀ% ,A FORM tag showing a change to this default assumption shown in the HEADer record can be used subordinate to an individual place structure to show the variant jurisdictional levels.ƀ% ,A place of origin that is not necessarily a birth place is shown by preceding the place name with the word "of." Missing or illegible characters within a place name are indicated by ... (ellipses).ƀ%  Y,  POSSESSIONS: = $~~H{Size=1:247},#/..XXԌ,A list of possessions (real estate or other property) belonging to this individual, separated by commas.ƀ%  Y  PRODUCT_NAME: =~~H{Size=1:90} ,The name of the software product that produced this transmission.ƀ%  Yw PUBLICATION_DATE: =~~H{Size=1:90} ,ƀ% ,The date this source was published or compiled.ƀ%  Y  PUBLICATION_EDITION: =~~H{Size=1:90} ,A description of the specific version of the publication which is being referenced.ƀ%  Y  PUBLICATION_NAME: =~~H{Size=1:90} ,The name of a publication such as a book, pamphlet, periodical, newspaper, or other monographic publication.ƀ%  Y}  PUBLICATION_PLACE: =~~H{Size=1:120}  ,The name of the place (city, state) where an item was published or the location of the publisher's main office.ƀ%  Y   PUBLICATION_TYPE: =~~H{Size=4:12} [ BOOK | PERIODICAL | NEWSPAPER | UNPUBLISHED | ELECTRONIC ]  Y  PUBLISHER_NAME: =~~H{Size=1:90} ,The name of the publisher of the referenced publication.ƀ%  Y  QUALITY_OF_DATA: =~~H{Size=1:1, Type=NUMBER} ,[ 0 | 1 | 2 | 3 ]ƀ% ,The submitter's assessment of the reliability of the information for the associated fact: ƀ% 0 = Unreliable evidence or data was estimated. 1 = Direct or primary evidence with some question of reliability or potential for bias for example, an autobiography). 2 = Secondary evidence. 3 = Direct and primary evidence used, or by dominance of the evidence.  Y!  RECORD_IDENTIFIER: =~~H{Size=1:18} ,An identification number assigned to each record within a specific data base. If this identifier is associated with a preceding colon (:), then it is the record number within the registered resource identified by the data that precedes the (:) else it is a specific reference to a record within the current database if no registered resource identifier precedes the (:). If the colon is not present it is the identification of a record within the current GEDCOM transmission file.ƀ%  Y(  REGISTERED_RESOURCE_IDENTIFIER: =~~H{Size=1:18} ,This is an identifier assigned to a resource data base which is available through access to an available network. (Future plans.)ƀ%  Y+  RELATIONSHIP_ROLE_TAG: =~~H{Size=1:90} [ BROT | CHIL | FATH | HEIR | HUSB | MOTH | PARE | PHUS | PWIF | SIBL |,$/..XXԌ SIST | WIFE ]  Y  RELIGIOUS_AFFILIATION: =~~H{Size=1:90} ,A name of the religion with which this person or record was affiliated.ƀ%  Y  RELIGIOUS_NAME: =~~H{Size=1:120} ,A name given to a person to be used in connection with a religion.ƀ%  YJ  REPOSITORY_NAME: =~~H{Size=1:90} ,The official name of the archive in which the stated source material is stored.ƀ%  Y  ROLE_DESCRIPTOR: =~~H{Size=1:90} ,A word or phrase that identifies the role of each person in the event being described. This should be the same word or phrase, and in the same language, that the recorder used to define the role in the actual record. This is used in connection with the ROLE_TAG.ƀ%  Y  ROLE_TAG: = $~~H{Size=1:20} [ BUYR | CHIL | FATH | GODP | HDOH | HDOG | HEIR | HFAT | HMOT | HUSB |  INFT | LEGA | MEMBER| MOTH | OFFI | PARE | PHUS | PWIF | RECO | REL |  ROLE | SELR | TXPY | WFAT | WIFE | WITN | WMOT | INDI ] ,A tag that indicates the role of the individuals mentioned in a source event record. If the above list does not include the role being cited, use the ROLE_TAG followed by a ROLE_DESCRIPTOR to define the role. (See appendix A for the definition of these tags and Appendix B for additional ROLEs which have been proposed as GEDCOM tags). Names of individuals mentioned in the event but their role was not mentioned, should be identified by using the INDI role tag. Any associations between others of known roles and this individual can be shown by using the ASSOciation pointer.ƀ%  Y  SCHOLASTIC_ACHIEVEMENT: =~~H{Size=1:247}  Yk A description of a scholastic or educational achievement or pursuit.  Y= SEARCH_STATUS: =~~H{Size=1:90} ,[ ACTIVE | FOUND | NO | ORDERED | PLANNED | PROVED ]ƀ% ,A field that shows the research status with respect to the cited source. Where:ƀ% ACTIVE =" $This source is currently being searched. ƀ% FOUND =" $Part or all of the expected information has been found.ƀ% NO =" $This source is no longer in use because the information could not be found.ƀ% ORDERD =" $A request for this source has been sent to the Repository. ƀ% PLANNED=" $This source is to be examined. ƀ% PROVED =" $This source has been reconciled with the data in this record.ƀ%  YX%  SEARCH_STATUS_DATE: =~~H{Size=1:90} ,ƀ% ,The date on which the current SEARCH_STATUS was set.ƀ%  Y(  SERIES_VOLUME_DESCRIPTION: =~~H{Size=1:247} ,A description of a successive publication. The description should identify the timing of the publication, for example, Spring, Summer, Fall, Winter. The description should also state the volume number of periodicals or of multivolume books.ƀ% ,%/..XXԌ Y  SEX_VALUE: = $~~H{Size=1:7} ,A code that indicates the sex of the individual:ƀ%  M = Male  F = Female  Y  SIGNATURE_INFO: =~~H{Size=1:90} ,A description of the capabilities of this person to sign documents, the symbol used in signing, did they know how to sign, did they use a model to produce a signature.ƀ%  Y3  SITE_NAME: = $~~H{Size=1:90} ,The name of a specific site associated with an event, address, or place.ƀ%  Y  SOCIAL_SECURITY_NUMBER: =~~H{Size=9:11} ,A social security identification number assigned to this person.ƀ%  Y  SOURCE_CALL_NUMBER: =~~H{Size=1:90} ,An identification number used to file and retrieve items from the holdings of a repository.ƀ%  Yg  SOURCE_CLASS_DESCRIPTOR: =~~H{Size=1:25} ,A descriptive word or phrase that classifies the type of source being cited. This descriptor is used only when none of the classifications defined under the fit this source type. Systems that display data from the GEDCOM form should be able to display the descriptor value in their screen or printed output.ƀ%  Y SOURCE_CLASSIFICATION_CODE: =~~H{Size=7:90} [ BOOK | CENSUS | CHURCH | COURT | HISTORY | INTERVIEW | JOURNAL |  LAND | LETTER | MILITARY | NEWSPAPER | PERIODICAL | PERSONAL |  RECITED | TRADITION | VITAL | OTHER! ] X ~wx (#%'0*,.8135@8:.ƀ% ,Systems that display data from the GEDCOM form should be able to display the descriptor value in their output.ƀ% X \9~wx (#%'0*,.8135@8: ,The name of the lowest jurisdiction that encompasses all lowerlevel places named in this source. For example, "Franklin, Idaho" would be used as a source jurisdiction place for events occurring in the various towns within Franklin county but "Idaho" would be used as a source jurisdiction place if the source records referenced other counties in Idaho besides Franklin county.ƀ%  Y  SOURCE_TEXT: = ${Size=1:247}~~H ,ƀ% ,A verbatim copy of any description contained within the source. This indicates notes that are actually contained in the source document, not the submitter's opinion about the source. ƀ%  Y;  SUBMITTER_TEXT: =~~H{Size=1:247} ,Comments or opinions from the submitter.ƀ%  Y  SYSTEM_NAME: =~~H{Size=1:20} ,The name of the sending or receiving GEDCOMcompatible product. The system name for the sending system was obtained when the product was registered as a GEDCOM-compatible product. All GEDCOM transmissions must be so identified. The system name used with the DESTination tag should be:ƀ% X ~wx (#%'0*,.8135@8: TO |  FROM |  TO ] ,The range in time of an event or set of events, inclusive. The choice FROM indicates a range from a beginning date to an indefinite future date. This differs from the date range notation in that the date range is to indicate that an event took place on a given date within the range. The time period date indicates that the event or events cover or happened over the time period specified.ƀ% ,The choice TO indicates from an indefinite beginning to a specified date.ƀ% Examples: FROM 1904 to 1915 FROM 1904 TO 1905  Yz TIME_VALUE: = ${Size=1:10} [ hh:mm:ss.fs ] ,The time of a specific event, usually a computertimed event, where:ƀ% hh = hours on a 24 hour clock mm = minutes ss = seconds, (optional) fs = decimal fraction of a second, (optional)  Y  TRANSMISSION_DATE: =~~H{Size=10:11} ,ƀ% The date that this transmission was created.  Yh  TYPE_OF: =  ${Size=1:20} ,A user-defined number or text that the submitter uses to identify this record. For instance, it may be a record number within the submitter's automated or manual system, or it may be a page and position number on a pedigree chart.ƀ%  Y  USER_TAG_DEFINITION: = ,A formal description of the user defined tag. This description can be used by the receiving system to give meaning to the user defined tags. (See Chapter 2, User Defined Tags section.)ƀ%  Y"  VERSION_NUMBER: =~~H{Size=1:15} ,An identifier that represents the version level assigned to the associated product. It is defined and changed by the creators of the product.ƀ%  Y@&  XREF: =  $~~H{Size=1:15} ,Either a pointer or a crossreference identifier. If this element appears before the tag in a GEDCOMline, then it is a crossreference identifier. If it appears after the tag in a GEDCOMline, then it is a pointer. The method of delimiting a pointer or crossreference identifier is to enclose the pointer or cross reference identifier within at-signs (@), for example, @I123@. A XREF may not begin with a number sign (#). This is to avoid confusion with an escape sequence prefix (@#). The use of a colon (:) in the XREF is reserved for creating future network crossreferences.ƀ%,(/..XXԌ Y ԙ XREF:ANY: = $~~H{Size=1:15} A universal pointer. It may point to any other crossreference identifier type.  Y  XREF:EVEN: = $~~H{Size=1:15} A pointer to or a cross reference identifier of a source event record.  Y3  XREF:FACT: = $~~H{Size=1:15} A pointer to or a cross reference identifier of a facts record.  Y  XREF:FAM: = $~~H{Size=1:15} ,ƀ% ,A pointer to or a cross reference identifier of a family record.ƀ%  Y}  XREF: INDI: = $~~H{Size=1:15} ,ƀ%  YP ,A pointer to or a cross reference identifier of an individual record. ƀ%  Y" XREF: NOTE: = $~~H{Size=1:15} ,ƀ% ,A pointer to or a cross reference identifier of a note record.ƀ%  Y  XREF:REPO: = $~~H{Size=1:15} ,ƀ% ,Either a pointer to a REPOsitory, a SUBMitter, or an INDIvidual record, or a cross reference identifier of a repository record.ƀ%  YU  XREF:REC!ID: = $~~H{Size=1:15} ,[ | | ] ƀ% ,Enclosed in atsigns (@), this is a pointer to a context within a record. Normally the pointer will only be used to point to role contexts within the current event record but the principle should allow the reference to a context within a specific record within a specific file. The following are valid ways of representing this pointer:ƀ% X ~wx (#%'0*,.8135@8:, within a specific record within a specific file , that logically replaces the context containing the cross reference pointer. (Future.)ƀ%A @REC!ID@ =A A (A pointer to a specific context within a specific record within the current GEDCOM transmission.ƀ%A not valid: @!ID@ =A A (A pointer to a specific context within the current record of this GEDCOM transmission must also contain the record level pointer, such as @I13!3@.ƀ%A X A ~wx (#%'0*,.8135@8:ƀ%,)/..XXԌ,Either a pointer to a SOURce, a SUBMitter, or an INDIvidual record, or a cross reference identifier of a source record.ƀ%  Y  XREF:SUBM: = $~~H{Size=1:15} ,ƀ% ,Either a pointer to a SUBMitter, or an INDIvidual record, or a cross reference identifier of a submitter record.ƀ%  YI  YEAR: =  $~~H{Size=3:4, Type=NUMBER} ,A numeric representation of the calendar year in which an event occurred. ƀ%  Y  YEAR_ALTERNATIVE: =~~H{Size=1:1, Type=NUMBER} ,A year modifier which shows the possible date alternatives for pre1752 date brought about by a calendar change, for example, 15 Dec 1752/3.ƀ%  X  COMPATIBILITY WITH OTHER GEDCOM VERSIONS X ~wx (#%'0*,.8135@8:/..XX The additional event and roll tags below have not yet been standardized. They are shown here in this draft form to obtain opinions as well as definitions. We will standardize as many as makes sense by the time the draft is finalized. The underscore '_' in front of the tags indicate the tags which have not been standardized and should be structured as user defined tags complete with your own definition and classification using the ISA tag. The other tags, the ones with the asterisk '*' have been standardized and defined in the 5.x Appendix A. Tags not appearing in Appendix A are not used in any of the lineagelinked structures of 5.x and were therefore dropped from the standard approved list.  (h0p (h0p (h0p, (h0p  e1 Events:   YS TAG: TAG NAME DEFINITION  _ABJUR, , "Abjuration _ABSOL, , "Absolution ADOP, , "Adoption* _APPRN, , "Apprenticeship BAPM, , "Baptism* BIRT, , "Birth* CENS, , "Census* _CHARTR, , "Charter CHR, , "Christening* _CITZN, , "Citizenship _CIVIL, , "Court Civil _CNFSCTN, , "Confiscation _COMUN, , "Communion CONF, , "Confirmation*hh2: _CRIME, , "Court Criminal _CRTULRY, , "Cartulary DEAT, , "Death* _DEAT_NOTE, , "Death_Notice DIV, , "Divorce* _DIV_ANUL, , "Divorce_Annulment _DIV_SEP, , "Divorce_Separation _DOWRY, , "Dowry _DPORTN, , "Deportation EDUC, , "Education* EMIG, , "Emigration* _EMPLYMT, , "Employment _ENRLMNT, , "Enrollment matriculation _EXCUTN, , "Execution _F_COMM, , "First_Communion _FUNRL_HOME, , "Funeral Home ,?/..XX  e Events: (cont')  X"  TAG: TAG NAME DEFINITION  _GALLEY, , "Galley GRAD, , "Graduation* IMMI, , "Immigration*hh2: _INTRO, , "Introduction _LAND, , "Land _LND_LEAS, , "Land_Lease _LND_PURC, , "Land_Purchase _MARR_BTRO, , "Marriage_Betrothal _MARR_CMLAW, , "Marriage Common Law _MARR_CNSNU, , "Marriage_Consanguinity marriage to blood relatives _MARR_CNTRC, , "Marriage_Contract _MARR_DIMIS, , "Marriage_Dimissorial@:© permission to get married in another jurisdictionƀ% _MARR_DISPN, , "Marriage_Dispensations _MARR_ENGA, , "Marriage_Engagements _MARR_INTNT, , "Marriage_Intention _MARR_REHAB, , "Marriage_Rehabilitation _MARR_BANN, , "Marriage_Banns AnnouncementsppH MARR, , "Marriage* MILI, , "Military* _MILIINDU, , "Military_Induction _MILI_DIS, , "Military_Discharge _MISS_PRSN, , "Missing Person _NAME_CHNG, , "Name Changehh2 NATU, , "Naturalization* ORDN, , "Ordination* _PASL, , "Passenger_List _PASP, , "Passport _POLI_RPT, , "Police_Reports _POPL_REG, , "Population_Register _POOR_LAW, , "Poor_law PROB, , "Probate* _ROSTR, , "Roster _S_COMM, , "Solemn_Communion _SASINE, , "Sasine _SEPRTN, , "Separation _SLAVE, , "Slavery ,@/..XX  e Events: (cont')  X"  TAG: TAG NAME DEFINITION  TXPY, , "Tax_payer* _TSTMNT, , "Testament _VOTE_REG, , "Voting_Registration _VOW, , "Vow WILL, , "Will*  e< Roles: The following are roles which could be used to describe participants in events. The status of these tags are the same as those listed for the event tags listed above. TAG: TAG NAME DEFINITION  _ANCE, , "Ancestor _APLCNT, , "Applicanthh2 _APPRN, , "Apprenticehh2 _APRSR, , "Appraiserhh2 _AUNT, , "Aunt((+ _BISHP, , "Bishop((+ _BOARDR, , "Boarder((+ _BOROWR, , "Borrowerhh2 _BRID, , "Bride((+ _BRO, , "Brother((+ BUYR, , "Buyer* _CAPT, , "Captain CHIL, , "Child* _CLRGY, , "Clergymenhh2 _CMDR, , "Commanderhh2 _COUSN, , "Cousins((+ _CREW, , "Crew _DEAD, , "Deceasedhh2 _DESC, , "Descendanthh2 _EMPLYR, , "Employer _EXCUTR, , "Executor FATH, , "Father* _FIANCE, , "Fiance _FREND, , "Friend V*A/..XX TAG: TAG NAME DEFINITION  _GODF, , "Godfatherhh2 _GODM, , "Godmotherhh2 GODP, , "Godparent*hh2 _GR_AUNT, , "Grand_Aunthh2 _GR_FATH, , "Grand_Fatherhh2 _GR_MOTH, , "Grand Mother _GR_UNCL, , "Grand_Unclehh2 _GROO, , "Groom _GUARDN, , "Guardianhh2 HDOH, , "Head_of_house* _HEIR, , "Heir HUSB, , "Husband* INFT, , "Informant*hh2 _INSTR, , "Instructorhh2 _JRNYMN, , "Journeymanhh2 _JUDGE, , "Judge _LENDR, , "Lender _M_WIFE, , "Midwife _MNSTR, , "Minister((+ _MONK, , "((+Monkhh2 MOTH, , "((+Mother* _MSTR, , "((+Master  _NIECE, , "Niece _NEPH, , "((+Nephew: _NLAW, , "((+In_law: _NLAW_BRO, , "Brother_in_lawhh2 _NLAW_DAU, , "Daughter_in_law: _NLAW_FATH, , "Father_in_law _NLAW_MOTH, , "Mother_in_lawhh2 _NLAW_SIS, , "Sister_in_lawhh2 _NLAW_SON, , "Son_in_law _NOTRY, , "Notary((+ _NUN, , "Nun _NURS, , "Nurse((+ OFFI, , "Official* _ORPHN, , "Orphan((+ _PHYSN, , "Physicianhh2 _PROF, , "Professor _PRISNR, , "Prisoner((+ _PATIENT, , "Patient((+ _PASNGR, , "Passengerhh2 ,B/..XX TAG: TAG NAME DEFINITION  RECO, , "Recorder* REL, , "Relative* _RNTR, , "Renter _RSDNT, , "Residenthh2 _SASSIER, , "Sassier((+ _SBLNG, , "Sibling SELR, , "Seller*((+ _SIS, , "Sister _SLAV, , "Slave _SOLDR, , "Soldier((+ SPOU, , "Spouse*((+ _SERVNT, , "Servant((+ _STEWRT, , "Stewart _STUD, , "Student((+ _TEACHR, , "Teacher((+ _TENANT, , "Tenant((+ _UNCL, , "Uncle((+ _WARD, , "Ward((+ WIFE, , "Wife* WITN, , "Witness*hh2 C/..XX    c_ 8 THE GEDCOM STANDARDă    cE < Appendix Că   c R8 ANSEL CHARACTER SETă     3Reproduced by permission from /American National Standards Institute l01430 Broadway, New York, N.Y. 10018 'D/..XX , (h0pX H d%'0*,.8135@8: