home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 17 / CD_ASCQ_17_101194.iso / vrac / geded101.zip / GEDCOM53.ZIP / GEDSTAND.T82 next >
Text File  |  1994-04-07  |  170KB  |  3,367 lines

  1.  
  2.  
  3.  
  4.  
  5.                                           THE GEDCOM STANDARD
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.                                            DRAFT Release 5.3
  16.  
  17.                                             4 November 1993
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.                                             Prepared by the
  27.                                        Family History Department
  28.                             The Church of Jesus Christ of Latter-day Saints
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35. Suggestions and Correspondence:
  36. GEDCOM Coordinator - 3T
  37. Family History Department
  38. 50 East North Temple
  39. Salt Lake City, UT 84150
  40. USA
  41.  
  42. Telephone (USA) 801-240-4534
  43.                     240-5225
  44.  
  45.  
  46.        "Copyright ■ 1987,1989,1992,1993 by Corporation of the President of The Church of Jesus Christ of Latter-day
  47.        Saints. This document may be copied for purposes of review or programming of genealogical software, provided this
  48.        notice is included. All other rights reserved."TABLE OF CONTENTS
  49.  
  50.  
  51. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
  52.  
  53.  
  54.     Purpose and Content of Document. . . . . . . . . . . . . . . . . . . . . . . . . .3
  55.        Changes in Version 5.x. . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
  56.        GEDCOM Product Registration . . . . . . . . . . . . . . . . . . . . . . . . . .5
  57.        GEDCOM Software Library . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
  58.  
  59.  
  60. Chapter 1
  61.     Data Representation Grammar. . . . . . . . . . . . . . . . . . . . . . . . . . . .6
  62.        Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
  63.        Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
  64.        Usage Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
  65.  
  66.  
  67. Chapter 2
  68.     Lineage-linked Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  69.        Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  70.        Lineage-linked Grammar Organization . . . . . . . . . . . . . . . . . . . . . 14
  71.        Record Structures of the Lineage-linked Form. . . . . . . . . . . . . . . . . 15
  72.        Substructures of the Lineage-linked Form. . . . . . . . . . . . . . . . . . . 19
  73.        Primitive Elements of the Lineage-linked Form . . . . . . . . . . . . . . . . 26
  74.        Compatibility with other GEDCOM versions. . . . . . . . . . . . . . . . . . . 42
  75.        Packaging the GEDCOM Transmission File  . . . . . . . . . . . . . . . . . . . 43
  76.        User Defined Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
  77.        Sample Lineage-linked GEDCOM Transmission . . . . . . . . . . . . . . . . . . 44
  78.        Sample EVENT_RECORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
  79.  
  80.  
  81. Chapter 3
  82.     Using Character Sets in GEDCOM . . . . . . . . . . . . . . . . . . . . . . . . . 47
  83.        8-bit ANSEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
  84.        Unicode (ISO 10646) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
  85.  
  86.  
  87. Appendix:
  88.     A  Lineage-linked GEDCOM Tag Definition. . . . . . . . . . . . . . . . . . . . . 50
  89.     B  Proposed Event and Role Tags. . . . . . . . . . . . . . . . . . . . . . . . . 62
  90.     C  Ansel Character Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
  91.                                             Introduction
  92.  
  93. GEDCOM was developed by the Family History Department of the Church of Jesus Christ of
  94. Latter-day Saints to provide a flexible uniform format for exchanging computerized genealogical
  95. data.  GEDCOM is an acronym for GEnealogical Data Communication.  GEDCOM is provided to
  96. foster the sharing of genealogical information and the development of a wide range of inter-operable
  97. software products to assist genealogists, historians, and other researchers.
  98.  
  99. Purpose and Content of This Document
  100.  
  101. This technical document is written for computer programmers, system developers, and technically
  102. sophisticated users. 
  103.  
  104. The chapters in this document contain the following GEDCOM specifications: 
  105.        *  Data Representation Grammar              *  Values
  106.        *  Lineage-linked GEDCOM Grammar            *  Character Sets
  107.        *  GEDCOM Transmission File                       
  108.  
  109. This document describes GEDCOM at two different levels.  The lower level defines a general-
  110. purpose data representation language for representing any kind of structured information in a
  111. sequential media.  The higher level defines specific content for data to be exchanged between
  112. compatible systems.
  113.  
  114. The lower level is known as the GEDCOM data format and deals with the syntax and
  115. identification of structured information in general, but does not deal with the semantic content of
  116. any particular kind of data.  The lower level GEDCOM format and the basic GEDCOM concepts
  117. are presented in chapter 1.  This chapter will also be useful to those using GEDCOM for other
  118. kinds of data, not just genealogical data.
  119.  
  120. The higher level is known as a GEDCOM form.  A GEDCOM form is defined for each kind of data
  121. that uses the GEDCOM data format.  The only GEDCOM form presented in this document is called
  122. the Lineage-linked GEDCOM form.  Other GEDCOM forms have been used for other kinds of
  123. data, including several that are not related to genealogy.  The Lineage-linked GEDCOM form is
  124. defined in chapter 2 and is the form used by commercial genealogical software systems for
  125. exchanging compiled, linked information about individuals with accompanying source citations and
  126. evidence records.  The other forms of GEDCOM are not publicly exchanged at this time, and are
  127. not discussed in this document.
  128.  
  129. Changes in Version 5.x
  130.  
  131. Prior versions of The GEDCOM Standard were released in October 1987 (3.0) and August 1989
  132. (4.0).  Versions 1 and 2 were drafts for public discussion and were not established as a standard.
  133.  
  134. This GEDCOM draft version (5.x) includes the first standard definition of the Lineage-linked form
  135. of GEDCOM and also includes the first major expansion of the Lineage-linked form since its initial
  136. use in GEDCOM 3.0.  The existing registered GEDCOM-compatible systems should still be able to
  137. exchange most data with newer systems that use this version and will still be considered GEDCOM-
  138. compatible for submitting information to the Family History Department. See chapter 2,
  139. "Compatibility with previous GEDCOM releases", for compatibility detail.
  140. There are several purposes for version 5.x of GEDCOM:
  141.  
  142.        *   Re-define the description of the GEDCOM data representation grammar in a shorter,
  143.            more precise format, for ease of understanding (see chapter 1).  The GEDCOM format
  144.            remains the same, even though the description of it is changed.
  145.  
  146.        *   Define the combinations of tags, values, and pointers allowed in the Lineage-linked form
  147.            (see chapter 2).  This is the form of GEDCOM currently exchanged by commercial
  148.            genealogical software systems, and it remains unchanged except for new tags and
  149.            upward-compatible  structural extensions listed below.  (The Lineage-linked form should
  150.            not be confused with other forms of GEDCOM, which apply the basic GEDCOM data
  151.            format with different tag, value, and pointer combinations for other purposes.)
  152.  
  153.        *   Define representations for support information such as source citations, and or notes. 
  154.            (See chapter 2 for suggested source citation structure in the Lineage-linked grammar.)
  155.  
  156.        *   Define additional EVENt and Role tags.
  157.  
  158.        *   Define user-defined ASSOciations with INDIviduals including direct family relationships.
  159.  
  160.        *   Require SOURce VERSion (product version) and GEDCom VERSion information in the
  161.            HEADer record.
  162.  
  163.        *   Define DATE modifier (ABT, BEF, AFT, BET) and a more rigorously defined regular
  164.            date format.
  165.        
  166. Some changes in Version 5.2 - 5.3 that were not in previous 5.x versions are:
  167.  
  168.        *   An address structure was defined to provide consistency to the addresses used in the
  169.            many different structures.  The Phone number is now subordinate to address.
  170.  
  171.        *   A new tag for marrital status (MSTAT) at the time of an event was used added to the
  172.            event structure.
  173.  
  174.        *   A mechanism for creating user-defined tags.  These are defined in a SCHEMA definition
  175.            in the header record.
  176.  
  177.        *   The inclusion of the Unicode standard (ISO 10646) as an additional character set standard
  178.            (see chapter 3).
  179.  
  180.        *   A MULTI_MEDIA_LINK structure was introduced to provide links to digitized video
  181.            and sound files.
  182.  
  183.        *   The NAME tag used in the SOURCE_STRUCTURE was changed back to the TITLe tag
  184.            to be used with the title of a book or article.
  185.  
  186.        *   The SOURCE_STRUCTURE was changed.  Compatibility may affect 5.x systems that
  187.            was using the CPLR, XLTR, AUTH, INFT tags in substructures within the source
  188.            structure.  See originator (ORIG) substructure for handling the name of the originator of
  189.            the source data.
  190.        *   Relocated all tags from the SUPPORT_INFO structure to the various structures where
  191.            they specifically apply.
  192.  
  193.        *   Added the use of the FORM {FORMAT} tag in both the HEADER and
  194.            PLACE_STRUCTURE.  The FORM tag in the header record subordinate to the PLAC
  195.            tag indicates that all of the locality names are specified in a consistent hiarchy as
  196.            specified by the value of the FORM.  For example; 2 FORM City, County, State. 
  197.            GEDCOM 5.2 used the TYPE tag subordinate to the PLAC tag for this purpose.
  198.  
  199.  
  200. GEDCOM Product Registration
  201.  
  202. Developers of GEDCOM-compatible products using the Lineage-linked form of GEDCOM (see
  203. chapter 2) should register their product by submitting the following information to the GEDCOM
  204. coordinator:
  205.  
  206.        *   A diskette containing a small sample of GEDCOM output from the product being
  207.            registered.  This should be data which represents all of the fields managed by your
  208.            system and that can be used for testing compatibility with other developer's systems.
  209.  
  210.        *   A proposed unique SOURce name in the GEDCOM header record to identify the product
  211.            (not the company).  This name can be up to 40 characters long, allowing mixed upper
  212.            and lower case, with no embedded spaces.  Use an underscore (_) to connect multiple
  213.            words instead of spaces or a combination of upper and lower case letters i.e.
  214.            FamilyRecords or Family_Records.  Family History reserves the right to require
  215.            uniqueness within the first 10 characters of this name.
  216.  
  217.        *   An optional text file containing relevant technical documentation about the product's
  218.            GEDCOM implementation.
  219.  
  220. GEDCOM Software Library
  221.  
  222. A library of unrestricted public domain source code, in the C programming language, is available to
  223. help reduce the work required to achieve GEDCOM compatibility.Chapter 1
  224.                                       DATA REPRESENTATION GRAMMAR
  225.  
  226. INTRODUCTION
  227.  
  228. This chapter describes the core GEDCOM data representation language.
  229.  
  230. The generic data representation language defined in this chapter may be used to represent any form
  231. of structured information, not just genealogical data, using a sequential stream of characters. 
  232.  
  233. CONCEPTS
  234.  
  235. A GEDCOM transmission represents a database in the form of a sequential stream of related
  236. records.  A record is represented as a sequence of tagged, variable-length lines, arranged in a
  237. hierarchy.  A line always contains a hierarchical level number, a tag, and an optional value.  A line
  238. may also contain a cross-reference identifier or a pointer.  The GEDCOM-line is terminated by a
  239. carriage return, a line feed character, or any combination of these.
  240.  
  241. The tag in the GEDCOM-line identifies the type of information contained in the line, in the same
  242. sense that a field-name identifies a field in a database record.  This means that the data is self-
  243. defining.  Tags allow a field to occur any number of times within a record, including zero times. 
  244. They also allow the use of different or new fields to be included in the GEDCOM data without
  245. introducing incompatibility, because the receiving system will ignore data which it does not
  246. understand and process only the data that it does understand.
  247.  
  248. The hierarchical relationships are indicated by the hierarchical level number.  Subordinate lines have
  249. a higher level number.  The hierarchy allows a line to have sub-lines, which in turn may have their
  250. own sub-lines, and so forth.  A line and its sub-lines constitute a context or enclosure, that is, a
  251. cluster of information pertaining directly to the same thing.  This hierarchical arrangement
  252. corresponds with the natural hierarchy found in most structured information.
  253.  
  254. A series of one or more lines constitutes a record.  The beginning of a new record is indicated by a
  255. line whose level number is 0 (zero).
  256.  
  257. A GEDCOM receiver system scans the input for expected information by looking for specific tags
  258. and processing the associated values.  Unrecognized tags (perhaps from a sending system whose
  259. database contains some different information) are handled by not processing the associated value nor
  260. its enclosed sub-lines; that is, the entire context is ignored. These are treated as exceptions by
  261. printing them in an exception report or saving them in some generic way.  Saved exception lines
  262. may be recombined when the data is exported.
  263.  
  264. In addition to hierarchical relationships, GEDCOM defines inter-record relationships which allow a
  265. record to be logically related to other records, without introducing redundancy.  These relationships
  266. are represented by two additional but optional parts of a line: a cross-reference pointer and a cross-
  267. reference identifier.  The cross-reference pointer "points at" a related record, identified by a
  268. required, matching unique cross-reference identifier.  The cross-reference identifier is analogous to a
  269. primary key in relational database terminology.
  270.  
  271.  
  272. GRAMMAR
  273.  
  274. The grammar for the GEDCOM data format--a data representation language--is defined in this
  275. chapter.  The grammar is a set of rules that specify what sequences of characters are valid
  276. GEDCOM expressions.  The rules are expressed as a set of pattern definitions, where each pattern
  277. is defined in terms of either a more primitive sub-pattern, or a constant.  Pattern definitions consist
  278. of the pattern name, a separator (:=), followed by either a constant, a more primitive sub-pattern,
  279. or a set of alternatives of these.  When a set is used, the alternatives are enclosed in square brackets
  280. [] with the alternatives separated by a vertical bar ([alternative_1 | alternative_2]).  Only one is to
  281. be selected.  The user can read the grammar components of the selected sub-pattern by substituting
  282. any sub-patterns until all sub-patterns are resolved. 
  283.  
  284. A GEDCOM transmission consists of a sequence of physical records, each of which consists of a
  285. sequence of gedcom_lines, all contained in a sequential file or stream of characters.  The
  286. following rules pertain to the gedcom_line:
  287. Ron's Example:
  288. 0 HEAD
  289. 1 SOUR testrun
  290. 1 DEST testrun
  291. 1 FILE bart.ged
  292. 1 DATE 01-24-1994
  293. 0 @I1@ INDI
  294. 1 NAME Henry  /SCUDDERR/
  295. 1 SEX M
  296. 0 TRLR
  297.        *   The beginning of a new physical record is designated by a line whose level number is 0.
  298.  
  299.        *   Physical records are intended to be small enough to fit within a memory buffer of typical
  300.            size, though absolute limits are not established.
  301.  
  302.        *   The total length of a GEDCOM-line, including leading white space and terminators, does
  303.            not exceed 255 characters.  Long text can be represented by using CONTinue or
  304.            CONCatenate tags.
  305.  
  306.        *   Leading white space (tabs, spaces, and extra line terminators) preceding a GEDCOM-line
  307.            should be ignored by the reading system.  Systems generating GEDCOM should not place
  308.            any white space in front of the GEDCOM-line (at least for the near future, see
  309.            "Compatibility With Previous GEDCOM Versions" at the end of chapter 2).
  310.  
  311.        *   Level numbers must not contain leading zeroes which are not significant, for example,
  312.            level one must be 1, not 01.
  313.  
  314.        *   GEDCOM-lines constructed with user defined tags must include a tag definition in the a
  315.            schema substructure in the transmission header record.  The user defined tag must begin
  316.            with an underscore (_).  The schema allows a receiving system to interpret the associated
  317.            data.  (See the User Defined Tags section in chapter 2 for more information).
  318.  
  319.  
  320. GRAMMAR SYNTAX
  321.  
  322. A gedcom_line has the following syntax:
  323.  
  324.     gedcom_line:=
  325.          level delim  opt_xref_id  tag  opt_line_value  terminator 
  326.        
  327.         for example:
  328.                                1 OCCU Teacher
  329.  
  330.     The components of the sub-patterns above are defined below in alphabetical order.  Some of the
  331.     components are defined in terms of more primitive sub-patterns:
  332.  
  333.     alpha:=
  334.      [ (0x41)-(0x5A) | (0x61)-(0x7A) | 0x5F ]
  335.        Any ASCII letter: A-Z, a-z, and (_) underscore 
  336.  
  337.     alphanum:=
  338.      [ alpha | digit ]
  339.  
  340.     any_char:=
  341.      [ alpha | digit | otherchar | (#) | ( ) | (@) (@) ]
  342.  
  343.     delim:=
  344.      [ (0x20) ]
  345.        space_character
  346.  
  347.     digit:=
  348.      [ (0x30)-(0x39) ]
  349.        One of the digits 0,1,2,3,4,5,6,7,8,9
  350.  
  351.     escape:=
  352.      [ (@) (#) escape_text (@) non_at ]
  353.       
  354.     escape_text:=
  355.      [ any_char | escape_text any_char ]
  356.        The escape_text is coded to meet the rules of a particular GEDCOM form.  For the lineage-
  357.        linked form the definitions are found in Chap. 2.
  358.  
  359.     level:=
  360.      [ digit | level digit ]
  361.        (Do not use non-significant leading zeroes such as 02.)
  362.  
  363.     line_item:=
  364.      [ pointer | escape | any_char ]
  365.  
  366.     line_value:=
  367.      [ line_item |    line_value  line_item ]
  368.  
  369.     non_at:=
  370.      [ alpha | digit | otherchar | (#) | ( ) ]
  371.  
  372.     null:=
  373.        () nothing
  374.  
  375.     opt_line_value:=
  376.      [ null | delim | delim line_value ]
  377.  
  378.     opt_xref_id:=
  379.      [ null | pointer delim ]
  380.  
  381.     otherchar:=
  382.      [(0x21)-(0x22) | (0x24)-(0x2F) | (0x3A)-(0x3F) | (0x5B)-(0x5E) | (0x60) |
  383.       (0x7B)-(0x7E) | (0x80)-(0xFF)]
  384.     Any ASCII character except control characters (0x00 - 0x1F), alphanum, space ( ), number sign
  385.     (#),  at character (@), and the DEL character (0x7F). 
  386.  
  387.     pointer:=
  388.      [ "@" alphanum pointer_string "@" ]
  389.  
  390.     pointer_char:=
  391.      [ non_at ]
  392.  
  393.     pointer_string:=
  394.      [ null | pointer_char | pointer_string pointer_char ]
  395.  
  396.     tag:=
  397.      [ alphanum | tag alphanum ]
  398.  
  399.     terminator:=
  400.      [ carriage_return |     line_feed |   carriage_return line_feed |
  401.        line_feed carriage_return ]
  402.  
  403.  
  404.  
  405. USAGE DESCRIPTION:
  406.  
  407.     alpha:=
  408.        The alpha characters include the underscore which is used to link word pieces together in
  409.        forming tag names or tag labels.
  410.  
  411.     any_char:=
  412.        Any character except the control characters found in the range of 0x00 - 0x1F.  If an @ is
  413.        desired as part of the line_value, it must be written in GEDCOM as a double @, ie., "3 doz.
  414.        @  $20.00" must be stored as "3 doz. @@ $20.00".
  415.  
  416.     delim:=
  417.        The delim (delimiter), a single space character, terminates both the variable-length level
  418.        number and the variable-length tag.  Note that space characters may also be present in a
  419.        value.
  420.  
  421.     escape:=
  422.        The  escape is a sequence in the grammar used to specify special processing, such as
  423.        switching character sets or calendars for date interpretation, or for indicating an inclusion of
  424.        a non_GEDCOM data form into the GEDCOM structure. The form of the escape sequence
  425.        is:
  426.        @# escape_text @ non_at.
  427.                       for example:
  428.                       @#DJULIAN@.
  429.        The non_at after the final at character (@) should be discarded if it is a space ( ). 
  430.        Otherwise, it should be retained as part of the text following the escape.  Output systems
  431.        should always place a space ( ) after the escape sequence.  
  432.  
  433.        The specific format of the escape sequence is defined for the specific GEDCOM form being
  434.        defined. (See chapter 2 for the escape sequence definition for the lineage-linked form).  
  435.  
  436.     escape_text:=
  437.        The escape_text is defined to meet the requirements of a particular GEDCOM form.  For the
  438.        lineage-linked form the definitions are found in Chap. 2.
  439.  
  440.     level:=
  441.        The level number works the same way as the level of indentation in an indented outline,
  442.        where indented lines provide detail about the item under which they are indented.  A line at
  443.        any level L is enclosed by and pertains directly to the nearest preceding line at level L-1. 
  444.        The Level L may increase by 1 at most.  Level numbers must not contain leading zeroes
  445.        which are not significant, for example level one must be (1), not (01).
  446.  
  447.        The enclosed subordinate lines at level L are said to be in the context of the enclosing
  448.        superior line at level L-1.  The meaning of a tag (see tag below) is interpreted in the context
  449.        of the tags of the enclosing line(s).  Take the following record about an individual's birth
  450.        and death dates, for example:
  451.  
  452.               0 INDI
  453.                 1 BIRT
  454.                   2 DATE 12 MAY 1920
  455.                 1 DEAT
  456.                   2 DATE 1960
  457.  
  458.        In this example, the expression DATE 12 MAY 1920 is interpreted within the INDI
  459.        (individual) BIRT (birth) context, representing the Individual's birth date.  The second
  460.        DATE is in the INDI DEAT (death) context.  The complete meaning of DATE depends on
  461.        the context.  (Note: the above example is indented according to the level numbers to make
  462.        the concept more obvious.  In the actual GEDCOM data there is no indentation, just level
  463.        numbers lined up vertically on the left margin).
  464.  
  465.        NOTE: Some existing systems provide an option to produce an indented GEDCOM output
  466.        for user readability, using space or tab characters between the terminator and the level
  467.        number of the next line to visibly show the hierarchy.  Also, some have suggested allowing
  468.        extra blank lines to visibly separate physical records.  These features may be incorporated
  469.        into the GEDCOM standard at some future time, but for now, such a change would render
  470.        some existing systems incompatible.  Therefore, we recommend that new systems be
  471.        prepared to discard extra carriage returns, line feeds, spaces and tabs immediately preceding
  472.        the level number during input.  Output should still be constrained to level numbers without
  473.        indentation or blank lines, until most receiving systems are prepared to deal with this change.
  474.  
  475.     line_value:=
  476.        The line_value identifies an object within the domain of possible values allowed in the
  477.        context of the tag.  The combination of the tag, the line_value, and the hierarchical context
  478.        of the supporting gedcom_lines provides the understanding of the enclosed values.  This
  479.        domain is defined by a specific grammar for representing a given GEDCOM form (see
  480.        chapter 2 for Lineage-linked grammar).
  481.  
  482.        Values whose source information contains illegible parts of the value should be indicated by
  483.        replacing the illegible part with ... (ellipses).
  484.  
  485.        Values are generally not encoded in binary or other abbreviation schemes for reducing space
  486.        requirements, and they are generally constrained to be understandable by a typical user
  487.        without decoding.  This is intended to reduce the decoding burden on the receiving software. 
  488.        A GEDCOM-optimized data compression standard will be defined in the future to reduce
  489.        space requirements.  Meanwhile, users may agree to compress and decompress GEDCOM
  490.        files using any compression system available to both sender and receiver.
  491.  
  492.        The line_value within the context of a tag hierarchy of gedcom_lines represents one piece of
  493.        information and corresponds to one field in traditional database or file terminology.
  494.  
  495.     opt_xref_id:=
  496.        (See pointer.)
  497.        The opt_xref_id is formed by any arbitrary combination of characters from the pointer_char
  498.        set.  The first character must be an alpha or a digit.  The opt_xref_id is not retained in the
  499.        receiving system, and may therefore be formed from any convenient combination of
  500.        identifiers from the sending system.  No meaning is attributed by the receiver to any part of
  501.        the opt_xref_id, other than its unique association with the associated record.  The use of the
  502.        colon (:) character is also reserved.
  503.  
  504.     otherchar:=
  505.      [(0x21)-(0x22) | (0x24)-(0x2F) | (0x3A)-(0x3F) | (0x5B)-(0x5E) | (0x60) |
  506.       (0x7B)-(0x7E) | (0x80)-(0xFF)]
  507.        Any ASCII character except control characters (0x00 - 0x1F), alphanum, space ( ), number
  508.        sign (#),  at character (@), and the DEL character (0x7F). 
  509.  
  510.        If any of these characters appear in the level, xref_ID, or pointer segments of the GEDCOM
  511.        line, then that substructure should be written to an exception file.  If any of these characters
  512.        appear in the value segment and the proper escape processing has not been invoked, then
  513.        they should be replaced by a (^) (0x5E) character, unless the character is a TAB (0x09)
  514.        character which can be replaced with a space (0x20) character.  These changes should also
  515.        be recorded on an exception file.
  516.  
  517.     pointer:=
  518.        A pointer stands in the place of the context identified by the matching xref_id. 
  519.        Theoretically, a receiving system should be prepared to follow a pointer to find any needed
  520.        value in a manner that is transparent to the logic of the subsystem that is looking for specific
  521.        tags.  This highly-flexible facility will probably be used more in the future.  For the time
  522.        being, however, the use of pointers is explicitly defined within the GEDCOM form (Such as
  523.        defined in Chapter 2).
  524.  
  525.        The pointer represents the association between two objects that usually reside in different
  526.        records.  There can, however, be an association between objects within the same logical
  527.        record.  If this condition exists it is indicated in the pointer record composition containing an
  528.        (!) character that separates the parent record's cross-reference ID from the specific
  529.        substructure's cross-reference ID which is at some subordinate level to the logical at level
  530.        zero.  The cross-reference ID of the substructure subordinate to a zero level record is always
  531.        composed of the Record ID number and the Substructure ID number, such as @I132!1@. 
  532.        By including the Record Id number in the pointers which associate objects within a record
  533.        will allow the GEDCOM processors to build the index only at the record level and then
  534.        search sequentially for the appropriate substructure cross reference ID.
  535.  
  536.        Complex logical record structures are divided into small physical records to accommodate
  537.        memory constraints, many-to-many relationships, and independent record creation and
  538.        deletion.
  539.  
  540.        The pointer must match a corresponding xref_id within the transmission, unless the colon (:)
  541.        character is present (future network reference to a permanent file record).  A pointer is
  542.        given instead of duplicating an object, though the logical result is equivalent.  An expanded
  543.        traversal of a record tree includes following the pointers to related records to some depth,
  544.        and splicing those records (logically) into the resultant expanded tree. Pointers may refer to
  545.        either records which have not yet appeared in the transmission (forward reference) or to
  546.        records that have already appeared earlier in the transmission (backward reference).  This
  547.        arrangement usually requires a preliminary pass to construct a look up table to support
  548.        random access by xref_id during subsequent passes. 
  549.  
  550.     tag:=
  551.        A tag consists of a variable length sequence of alphanum characters.  All user defined tags,
  552.        that is tags used which have not been defined by the GEDCOM standard must begin with an
  553.        underscore character. (0x95).  All user defined tags must be defined in the SCHEMA
  554.        substructure of the HEADer record. 
  555.  
  556.        The tag represents the meaning of the line_value within the context of the enclosing lines,
  557.        and contributes to the meaning of enclosed subordinate lines.  Specific tags are defined in
  558.        Appendix A.  
  559.  
  560.        Although existing tags are only three or four characters long, systems should prepare to
  561.        handle tags of any length. Tags will be unique within the first 15 characters.
  562.  
  563.        Valid combinations of specific tags, line_values, xref_ids, and pointers are constrained by
  564.        the GEDCOM form defined for representing a given kind of information (see chapter 2 for
  565.        the Lineage-linked form grammar).
  566.  
  567.     terminator:=
  568.        The terminator delimits the variable-length line_value and signals the end of the
  569.        gedcom_line. The valid terminator characters are:
  570.                        [     carriage_return |
  571.                              line_feed |
  572.                              carriage_return line_feed |
  573.                              line_feed carriage_return ]
  574.  
  575. Examples:
  576.  
  577.     The following are examples of valid but unrelated GEDCOM-lines:
  578.  
  579.               0 @1234@ INDI
  580.               . . .
  581.               1 AGE 13
  582.               . . .
  583.               1 CHIL @1234@
  584.               . . .
  585.               1 NOTE This is a note field that is
  586.               2 CONT continued on the next line.
  587.  
  588.     The first line has a level number 0, a xref_id of @1234@, an INDI tag, and no value.  The
  589.     second line has a level number 1, no xref_id, an AGE tag, and a value of 13.  The third line
  590.     has a level number 1, no xref_id, a CHIL tag, and a value of a pointer to a xref_id named
  591.     @1234@.                                   Chapter 2
  592.                                         LINEAGE-LINKED GRAMMAR
  593.  
  594. INTRODUCTION
  595.  
  596. This chapter describes the specific tag, value, and pointer combinations used for exchanging
  597. lineage-linked genealogical information in the GEDCOM format.  Lineage-linked data pertains to
  598. individuals linked in family relationships across multiple generations.  The chapter also addresses
  599. specific compatibility issues pertaining to previous Lineage-linked GEDCOM releases and contains a
  600. sample Lineage-linked GEDCOM transmission.
  601.  
  602. The Lineage-linked grammar defined in this chapter is based on the general framework of the
  603. GEDCOM data representation grammar defined in the Chapter 1.  The lineage-linked grammar
  604. defines the GEDCOM form used by commercial genealogical software systems to exchange data. 
  605. Other specialized GEDCOM-based grammars have been created for different uses.  These other uses
  606. of the general-purpose GEDCOM data representation should not be confused with this specific usage
  607. for lineage-linked genealogical data, as defined in this chapter as the only approved form of
  608. GEDCOM exchanged by commercial genealogical software systems at this time.
  609.  
  610. LINEAGE-LINKED GRAMMAR ORGANIZATION
  611.  
  612. This Lineage-linked GEDCOM grammar is organized into three sections:
  613.  
  614.     * Record structure components
  615.     * Substructure patterns         (Arranged alphabetically by substructure name)
  616.     * Primitive elements                   (Arranged alphabetically by primitive name)
  617.  
  618. Structures and substructures are indicated by enclosing the structure name within double angle
  619. <<brackets>>.  Primitive element patterns are enclosed in single angle <brackets>.
  620.  
  621. The definition of each structure consists of the structure name, a separator (:=), and the structure's
  622. component pattern.  This pattern consists of (a) GEDCOM-lines composed of primitive elements,
  623. and/or (b) substructures.  Some primitive elements consist of two or more alternative sub-pattern
  624. choices.  These choices are shown by listing the alternative sub-patterns between opening and
  625. closing square [brackets] and separating each choice with a vertical bar (|), meaning that exactly
  626. one of the alternate substitutions must be selected.  Some definitions of primitive elements use the
  627. definition of other primitive elements to complete their definition. This is shown by including the
  628. name of the detailed element type inside angle <brackets> in the definition.
  629.  
  630. The number of sub-pattern occurrences allowed within a pattern is defined in an occurrence
  631. definition in curly {braces} on each line.  This number indicates the minimum and maximum
  632. number of occurrences allowed for a pattern component in the form {minimum:maximum}.  Note
  633. that minimum and maximum occurrence limits are defined relative to the enclosing superior line. 
  634. This means that a required line (minimum = 1) is not required in an instance where the optional
  635. enclosing line is not given.  Similarly, a line occurring only once (maximum = 1) may occur
  636. multiple times as long as each occurs only once under its own multiple-occurring superior line.
  637.  
  638. The level numbers for any sub-structure are represented as (n), (+1), (+2), and so forth, so that
  639. they may be used in more than one place at different starting level numbers. In these cases, (n)
  640. equals the level number where the pattern first appears, and the (+1) means one level greater than
  641. level n, (+2) means two levels greater than level n, and so forth.
  642.  
  643. Unless stated otherwise, the only ordering imposed on GEDCOM-lines within an enclosure arises
  644. when multiple opinions or other items are presented for which only one may be expected by a
  645. receiving system.  For example, a person may have been known by more than one name, or
  646. evidence may suggest a birth either in 1840 in New York or in 1837 in Pennsylvania.  In these
  647. cases, the most credible or preferred information is listed first, followed by less credible or less
  648. preferred items. The QUAY tag may also be used to show the preferred data (see appendix A). 
  649. Systems that support only a single field within a context should use the first item in the list.
  650.  
  651. Conflicting dates or places of an event should be represented in separate event structures to provide
  652. a place for the accompanying source citations, rather than place multiple dates or multiple places
  653. under the same enclosing event.
  654.  
  655. Even though no other ordering is defined beyond the one described above, some GEDCOM
  656. programming tools optimize performance based on the assumption that tags generally appear in a
  657. typical order.  Therefore, sending systems are encouraged to present GEDCOM structures in the
  658. same general order as the one given in these patterns, unless there is a reason to use a different
  659. sequence. 
  660.  
  661. This form uses the tag TYPE as a subordinate tag to names, places, events, etc.  The intent of this
  662. tag is meant to further define its superior tag for the viewer only, it is not intended to inform a
  663. computer program how to process the data.  The difference between this value and a note value
  664. would be that displaying systems should always display the type value when they display the
  665. associated data.  Therefore, cautious consideration should be used in using the TYPE tag. 
  666.  
  667. RECORD STRUCTURES OF THE LINEAGE-LINKED FORM
  668.  
  669. LINEAGE_LINKED_GEDCOM:=
  670.       This is a model of the Lineage-linked GEDCOM structure for submitting data to other
  671.       lineage-linked GEDCOM processing systems.  A header and a trailer record are required and
  672.       they enclose any number of data records.
  673.  
  674.       0  <<HEADER>>                                                       {1:1}           
  675.       0  <<RECORD>>                                                       {0:M}           
  676.       0 TRLR                                                              {1:1}           
  677.  
  678.       There are specific subordinate GEDCOM-lines that may be used as subordinate GEDCOM-
  679.       lines to other superior GEDCOM-lines.  For example:
  680.          1 BIRT
  681.          2 DATE 02 Oct 1937
  682.          3 QUAY 1
  683.       In the above example QUAY at level 3 indicates how reliable or correct the birth date value
  684.       is.  The QUAY tag applies to any tag that contains a value.  This tag is not shown in any of
  685.       the structures but the reader and writer of GEDCOM should expect that the QUAY tag
  686.       could be present as a subordinate tag to any tag that has an associated value.
  687.  
  688. HEADER:=
  689.       The header structure provides information about the entire transmission.  The SOURce system
  690.       name identifies which system sent the data.  The DESTination system name identifies the
  691.       receiving system.  Submission to the Family History Department for Ancestral File is
  692.       ANSTFILE. For LDS temple submissions it is TempleReady.
  693.  
  694.  
  695.  
  696.       n  HEAD                                                             {1:1}
  697.          +1 SOUR <SYSTEM_NAME>                                            {1:1}
  698.             +2 VERS <VERSION_NUMBER>                                      {1:1}
  699.             +2 NAME <PRODUCT_NAME>                                        {0:1}
  700.             +2 CORP <CORPORATE_NAME>                                      {0:1}
  701.                +3 <<ADDRESS_STRUCTURE>>                                   {0:1}
  702.             +2 DATA <NAME_OF_SOURCE_DATA>                                 {0:1}           
  703.                +3 DATE <PUBLICATION_DATE>                                 {0:1}
  704.          +1 DEST <SYSTEM_NAME>                                            {0:1}           
  705.          +1 DATE <TRANSMISSION_DATE>                                      {0:1}
  706.             +2 TIME <TIME_VALUE>                                          {0:1}           
  707.          +1 SUBM @XREF:SUBM@                                              {1:1}           
  708.          +1 FILE <FILE_NAME>                                              {0:M}           
  709.          +1 COPR <COPYRIGHT_STATEMENT>                                    {0:1}           
  710.             +2 CONT <TEXT>                                                {0:M}           
  711.          +1 SCHEMA                                                        {0:1}
  712.             +2 <<USER_TAG_SCHEMA>>                                        {1:M}
  713.          +1 GEDC                                                          {1:1}           
  714.             +2 VERS <VERSION_NUMBER>                                      {1:1}           
  715.             +2 FORM <GEDCOM_FORM>                                         {0:1}
  716.          +1 CHAR <CHARACTER_SET>                                          {0:1}           
  717.             +2 VERS <VERSION_NUMBER>                                      {0:1}
  718.          +1 LANG <LANGUAGE_OF_TEXT>                                       {0:1}
  719.          +1 PLAC                                                          {0:1}
  720.             +2 FORM <PLACE_HIERARCHY>                                     {1:1}
  721.  
  722. RECORD:=
  723.       [   
  724.          n  <<EVENT_RECORD>>                                              {0:1}    
  725.       |                                                                 
  726.          n  <<FAMILY_RECORD>>                                             {0:1}      
  727.       |
  728.          n  <<INDIVIDUAL_RECORD>>                                         {0:1}
  729.       |
  730.          n  <<NOTE_RECORD>>                                               {0:1}
  731.       |
  732.          n  <<REPOSITORY_RECORD>>                                         {0:1}
  733.       |
  734.          n  <<SOURCE_RECORD>>                                             {0:1}    
  735.       |                                                                         
  736.          n  <<SUBMITTER_RECORD>>                                          {1:1}
  737.       ]
  738.  
  739. FAMILY_RECORD:=
  740.       n  @XREF:FAM@ FAM                                                   {0:1}           
  741.          +1 HUSB @XREF:INDI@                                              {0:1}           
  742.          +1 WIFE @XREF:INDI@                                              {0:1}           
  743.          +1 CHIL @XREF:INDI@                                              {0:M} 
  744.          +1 REFN <USER_REFERENCE_NUMBER>                                  {0:M}
  745.          +1 <FAM_EVNT_TAG>                                                {0:M}
  746.             +2 TYPE <FAMILY_EVENT_DESCRIPTOR>                             {0:1}
  747.             +2 DATE <DATE_VALUE>                                          {0:1}           
  748.             +2 <<PLACE_STRUCTURE>>                                        {0:1}
  749.          +1 <DIV_EVNT_TAG>                                                {0:M}
  750.             +2 TYPE <DIVORCE_DESCRIPTOR>                                  {0:M}           
  751.             +2 DATE <DATE_VALUE>                                          {0:1}           
  752.             +2 <<PLACE_STRUCTURE>                                         {0:1}    
  753.          +1 ASSO @XREF:ANY@                                               {0:M}
  754.             +2 TYPE <ASSOCIATION_DESCRIPTOR>                              {0:1}    
  755.          +1 NCHI <COUNT_OF_CHILDREN>                                      {0:1}
  756.          +1 <<LDS_FAM_ORDINANCE_EVENT>>                                   {0:M}           
  757.          +1 <<SOUR_STRUCTURE>>                                            {0:1}
  758.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  759.          +1 <<MULTI_MEDIA_LINK>>                                          {0:M}
  760.          +1 <<CHANGE_DATE>>                                               {0:M}
  761.  
  762. INDIVIDUAL_RECORD:=
  763.       The occurrence of FAMS and FAMC tags show {0:1}, however; when an individual is
  764.       referenced in a FAMily record as either a spouse or child, then this record must include a
  765.       corresponding FAMS and/or FAMC tags.  The association of one individual to another can be
  766.       represented by using the ASSO tag in the individual record to point to the record of the
  767.       associated individual.  The relationship or association is shown in the value field of the
  768.       subordinate TYPE tag.
  769.  
  770.       n  @XREF:INDI@ INDI                                                         
  771.          +1 <<INDIVIDUAL>>                                                {1:1}    
  772.          +1 FAMS @XREF:FAM@                                               {0:M}    
  773.          +1 FAMC @XREF:FAM@                                               {0:M}    
  774.             +2 <<CHILD_FAMILY_EVENT>>                                     {0:M}    
  775.          +1 ASSO @XREF:REC@                                               {0:M}
  776.             +2 TYPE <ASSOCIATION_DESCRIPTOR>                              {0:1}
  777.          +1 <<LDS_INDI_ORDINANCE_EVENT>>                                  {0:M}
  778.          +1 RFN <PERMANENT_RECORD_FILE_NUMBER>                            {0:M}    
  779.          +1 REFN <USER_REFERENCE_NUMBER>                                  {0:M}    
  780.          +1 AFN <ANCESTRAL_FILE_NUMBER>                                   {0:1}    
  781.          +1 ALIA @XREF:INDI@                                              {0:M}    
  782.          +1 ANCI @XREF:SUBM@                                              {0:M}    
  783.          +1 DESI @XREF:SUBM@                                              {0:M}    
  784.          +1 <<SOUR_STRUCTURE>>                                            {0:1}
  785.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  786.          +1 <<MULTI_MEDIA_LINK>>                                          {0:M}
  787.          +1 <<CHANGE_DATE>>                                               {0:M}
  788.  
  789. EVENT_RECORD:=
  790.       This structure represents event-oriented evidence information that is claimed as a basis for a
  791.       submitter's opinion expressed in Lineage-linked INDIVIDUAL and FAMILY records.  Event
  792.       records define an event in terms of a what happened, where and when it happened, and what
  793.       individuals are mentioned in the record.
  794.  
  795.       These event records in some cases will be the source for assertions made in compiling lineage-
  796.       linked data. SOURce pointers to the bibliographic description of where this event information
  797.       was recorded should be a part of this record.   
  798.       Evidence records from historical sources are kept separate from opinion records created by the
  799.       submitter.  The information contained in evidence records is not redundant with respect to the
  800.       information contained in submitter's opinions, even when names, dates, or places are the
  801.       same, because the authority for asserting the information is different.
  802.  
  803.       Roles of an event which pertain to the event itself are placed subordinate to the event tag. 
  804.       Roles of individuals mentioned in the event which are relationship roles such as the
  805.       "husband's father" is placed subordinate to the role tag of the groom.  For example, the
  806.       minister at a wedding's role would be represented by the 0 EVENt-MARRiage-OFFIciator
  807.       structure.  The father of the husband would be represented by the 0 EVENt-MARRiage-
  808.       HUSBand-FATHer structure.  
  809.  
  810.       n  @XREF:EVEN@ EVEN
  811.          +1 <<CHANGE_DATE>>                                               {0:M}
  812.          +1 <EVENT_TAG>                                                   {1:1} 
  813.             +2 TYPE <EVENT_DESCRIPTOR>                                    {0:1}
  814.             +2 DATE <DATE_VALUE>                                          {0:1}    
  815.             +2 <<PLACE_STRUCTURE>>                                        {0:1}    
  816.             +2 PERI <TIME_PERIOD>                                         {0:M}
  817.             +2 RELI <RELIGIOUS_AFFILIATION>                               {0:1}
  818.             +2 <<MULTI_MEDIA_LINK>>                                       {0:M}
  819.             +2 <<TEXT_STRUCTURE>>                                         {0:1}
  820.             +2 <<SOUR_STRUCTURE>>                                         {0:M}
  821.             +2 <<NOTE_STRUCTURE>>                                         {0:M}
  822.             +2 <ROLE_TAG>                                                 {0:M}
  823.                +3 TYPE <ROLE_DESCRIPTOR>                                  {0:1}    
  824.                +3 <<INDIVIDUAL>>                                          {0:1}    
  825.                +3 ASSO @XREF:INDI@                                        {0:M}
  826.                   +4 TYPE <ASSOCIATION_DESCRIPTOR>                        {1:1}
  827.                +3 <RELATIONSHIP_ROLE_TAG> [NULL | @XREF:INDI@ ]           {0:M}
  828.                   +4 TYPE <ROLE_DESCRIPTOR>                               {0:1}    
  829.                   +4 <<INDIVIDUAL>>                                       {0:1}    
  830.  
  831. NOTE_RECORD:=             /* must contain cross reference ID */
  832.       n  <<NOTE_STRUCTURE>>                                               {1:1} 
  833.          +1 <<CHANGE_DATE>>                                               {0:M}
  834.  
  835. REPOSITORY_RECORD:=       /* must contain cross reference ID */
  836.       n  <<REPOSITORY_STRUCTURE>>                                         {1:1}
  837.          +1 <<CHANGE_DATE>>                                               {0:M}
  838.  
  839. SOURCE_RECORD:=           /* must contain cross reference ID */
  840.       n  <<SOURCE_STRUCTURE>>                                             {1:1}
  841.          +1 <<CHANGE_DATE>>                                               {0:M}
  842.  
  843.  
  844. SUBMITTER_RECORD:=
  845.       The submitter record identifies individuals or organizations that contributed the opinion
  846.       information contained within the GEDCOM transmission.  All records in the transmission are
  847.       assumed to be submitted by the SUBMITTER referenced in the HEADer, unless a SUBMitter
  848.       reference inside a specific record points at a different SUBMITTER.
  849.                                                                               
  850.       n  @XREF:SUBM@ SUBM                                                 {1:1}
  851.          +1 <<NAME_STRUCTURE>>                                            {1:1}
  852.          +1 <<ADDRESS_STRUCTURE>>                                         {0:1}
  853.          +1 LANG <LANGUAGE_PREFERENCE>                                    {0:3}
  854.          +1 <<CHANGE_DATE>>                                               {0:M}
  855.  
  856.  
  857. SUBSTRUCTURES OF THE LINEAGE-LINKED FORM
  858.  
  859. ADDRESS_STRUCTURE:=
  860.       n  SITE <SITE_NAME>                                                 {0:1}
  861.       n  ADDR <ADDRESS_LINE>                                              {0:1}
  862.          +1 CONT <ADDRESS_LINE>                                           {0:M}
  863.          +1 PHON <PHONE_NUMBER>                                           {0:3}
  864.  
  865. BURIAL_STRUCTURE:=  
  866.       Used only when cemetery information is managed separately from the burial place name.  It is
  867.       permissible to include the cemetery name as the low level locality name; for example,
  868.       Richmond Cemetery, Richmond, Cache, Utah, USA.
  869.       n  CEME <CEMETERY_NAME>                                             {0:1}
  870.          +1 PLOT <BURIAL_PLOT_ID>                                         {0:1}
  871.  
  872. CHANGE_DATE:=
  873.       n  CHAN                                                             {1:1}           
  874.          +1 DATE <CHANGE_DATE>                                            {1:1}           
  875.             +2 TIME <TIME_VALUE>                                          {0:1}
  876.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  877.  
  878. CHILD_FAMILY_EVENT:=
  879.       [
  880.       n  ADOP                                                             {1:1}           
  881.          +1 TYPE <CHILD_FAMILY_EVENT_DESCRIPTOR>                          {0:1}
  882.          +1 AGE  <AGE_VALUE>                                              {0:1}
  883.          +1 DATE <DATE_VALUE>                                             {0:1}           
  884.          +1 <<PLACE_STRUCTURE>>                                           {0:1}           
  885.          +1 <<SOUR_STRUCTURE>>                                            {0:1}
  886.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  887.       |                                                                         
  888.       n  <<LDS_CHILD_SEALING_EVENT>>                                      {0:1}           
  889.       ]
  890.  
  891. CORRECTNESS_ASSESMENT:=
  892.       n  QUAY <QUALITY_OF_DATA>                                           {0:1}
  893.                          /* used subordinate to any tag containing a value */
  894.  
  895. EVENT_STRUCTURE:=
  896.       Information about an individual with respect to a specific event, such as the age, marital
  897.       status, religious affiliation of this individual at time of this event.  Keep in mind that this is
  898.       data specific to the individual owning this event and not the data that belongs to the source in
  899.       which this data was found.  For instance Immigration and Emigration events should use a
  900.       reference a source structure to show the SHIP and PORT information concerning the event. 
  901.       Roles of other individuals can be shown using the EVENt record.  A link to the event record
  902.       can be made by using the SOURce structure to point to the EVENt record.  The event record
  903.       in this case would be an evidence record supporting the assertions made in creating this event
  904.       structure.
  905.  
  906.       n  <EVENT_TAG>                                                      {1:1} 
  907.          +1 TYPE <EVENT_DESCRIPTOR>                                       {0:M}
  908.          +1 DATE <DATE_VALUE>                                             {0:1}    
  909.          +1 <<PLACE_STRUCTURE>>                                           {0:1}    
  910.             +2 <<BURIAL_STRUCTURE>>                                       {0:1}
  911.          +1 AGE <AGE_VALUE>                                               {0:1}
  912.          +1 MSTAT <MARITAL_STATUS>                                        {0:1}
  913.          +1 CAUS <CAUSE_OF_DEATH>                                         {0:1}
  914.          +1 RELI <RELIGIOUS_AFFILIATION>                                  {0:1}
  915.          +1 AGNC <GOVERNMENT_AGENCY>                                      {0:1}
  916.          +1 <<TEXT_STRUCTURE>>                                            {0:1}
  917.          +1 <<SOUR_STRUCTURE>>                                            {0:1}
  918.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  919.          +1 <<CHANGE_DATE>>                                               {0:M}
  920.  
  921. INDIVIDUAL:=
  922.       n  <<NAME_STRUCTURE>>                                               {1:M}
  923.       n  TITL <INDI_TITLE>                                                {0:M}    
  924.       n  SEX <SEX_VALUE>                                                  {0:1}    
  925.       n  <<EVENT_STRUCTURE>>                                              {0:M}
  926.       n  <<ADDRESS_STRUCTURE>>                                            {0:M}    
  927.       n  RELI <RELIGIOUS_AFFILIATION>                                     {0:M}    
  928.       n  NAMR <RELIGIOUS_NAME>                                            {0:M}
  929.          +1 RELI <RELIGIOUS_AFFILIATION>                                  {0:1} 
  930.       n  EDUC <SCHOLASTIC_ACHIEVEMENT>                                    {0:M}
  931.       n  OCCU <OCCUPATION>                                                {0:M}
  932.       n  SSN  <SOCIAL_SECURITY_NUMBER>                                    {0:M}    
  933.       n  IDNO <NATIONAL_ID_NUMBER>                                        {0:M}
  934.          +1 TYPE <TYPE_OF>                                                {1:1}
  935.       n  PROP <POSSESSIONS>                                               {0:M}
  936.       n  DSCR <PHYSICAL_DESCRIPTION>                                      {0:M}    
  937.          +1 CONT <PHYSICAL_DESCRIPTION>                                   {0:M}    
  938.       n  SIGN <SIGNATURE_INFO>                                            {0:M}
  939.       n  NMR <COUNT_OF_MARRIAGES>                                         {0:M}    
  940.       n  NCHI <COUNT_OF_CHILDREN>                                         {0:M}    
  941.       n  NATI <NATIONALITY>                                               {0:M}    
  942.       n  CAST <CASTE_NAME>                                                {0:M}    
  943.  
  944. LDS_CHILD_SEALING_EVENT:=
  945.       n  SLGC                                                             {1:1}
  946.          +1 TYPE <LDS_CHILD_SEALING_DESCRIPTOR>                           {0:1} 
  947.          +1 DATE <DATE_VALUE>                                             {0:1}           
  948.          +1 TEMP <TEMPLE_VALUE>                                           {0:1}           
  949.  
  950. LDS_FAM_ORDINANCE_EVENT:=
  951.       n  SLGS                                                             {1:1}           
  952.          +1 TYPE <LDS_FAM_ORD_DESCRIPTOR>                                 {0:1}
  953.          +1 DATE <DATE_VALUE>                                             {0:1}           
  954.          +1 TEMP <TEMPLE_VALUE>                                           {0:1}           
  955.  
  956. LDS_INDI_ORDINANCE_EVENT:=
  957.       n  <LDS_INDI_ORD>                                                   {1:1}           
  958.          +1 TYPE <LDS_INDI_ORD_DESCRIPTOR>                                {0:1}           
  959.          +1 DATE <DATE_VALUE>                                             {0:1}           
  960.          +1 TEMP <TEMPLE_VALUE>                                           {0:1}           
  961.          +1 <<SOUR_STRUCTURE>>                                            {0:1}
  962.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  963.  
  964. MULTI_MEDIA_LINK:=
  965.       n  AUDIO <ESCAPE_TO_AUXILLARY_PROCESSING>                           {0:1}
  966.       n  PHOTO <ESCAPE_TO_AUXILLARY_PROCESSING>                           {0:1}
  967.       n  VIDEO <ESCAPE_TO_AUXILLARY_PROCESSING>                           {0:1}
  968.  
  969. NAME_STRUCTURE:=
  970.       n  NAME <PERSONAL_NAME>                                             {1:1}
  971.          +1 TYPE <NAME_TYPE_DESCRIPTOR>                                   {0:1}
  972.          +1 <<SOUR_STRUCTURE>>                                            {0:1}
  973.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  974.  
  975. NOTE_STRUCTURE:=
  976.       This structure contains information originated by the submitter.
  977.       n  [ @XREF:NOTE@ | NULL ] NOTE [ <SUBMITTER_TEXT> | NULL ]          {1:1} 
  978.          +1  CONT <SUBMITTER_TEXT>                                        {1:M}      
  979.          +1  NOTE @XREF:NOTE@                                             {0:1}           
  980.  
  981. PLACE_STRUCTURE:=
  982.       n  PLAC <PLACE_VALUE>                                               {1:1}
  983.          +1 FORM <PLACE_HIERARCHY>                                        {0:1}
  984.          +1 <<ADDRESS_STRUCTURE>>                                         {0:1}
  985.          +1 <<SOUR_STRUCTURE>>                                            {0:1}
  986.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  987.  
  988. REPOSITORY_STRUCTURE:=
  989.       n  [ @XREF:REPO@ | NULL ] REPO                                      {1:1}
  990.             +2 NAME <NAME_OF_REPOSITORY>                                  {0:1}
  991.             +2 CNTC <NAME_OF_CONTACT_PERSON>                              {0:1}
  992.             +2 <<ADDRESS_STRUCTURE>>                                      {0:1}
  993.             +2 MEDI <MEDIA_TYPE>                                          {0:1}
  994.             +2 CALN <SOURCE_CALL_NUMBER>                                  {0:1}
  995.                +3 ITEM <FILM_ITEM_IDENTIFICATION>                         {0:1}
  996.                +3 SHEE <SHEET_NUMBER>                                     {0:1}
  997.                +3 PAGE <PAGE_NUMBER>                                      {0:1}
  998.             +2 REFN <MANUAL_FILING_IDENTIFICATION>                        {0:1}
  999.             +2 <<NOTE_STRUCTURE>>                                         {0:1}
  1000.  
  1001. SOURCE_STRUCTURE
  1002.       The source structure represents the submitter's basis (justification) for the opinions asserted in
  1003.       a lineage linked transmission.  This information is used by other researchers to (1) determine
  1004.       how much confidence to place in the associated assertions, (2) compare new evidence to old
  1005.       evidence from prior research, and (3) locate and examine the evidence to make an independent
  1006.       evaluation of it.  If a source is not explicitly cited for a given context, the source is by default
  1007.       ascribed to be the personal opinion of the submitter, with no further basis for its credibility.
  1008.  
  1009.       The justification takes the form of a description of the source from which the evidence was
  1010.       obtained, and may include a machine-readable representation of the evidence itself, such as an
  1011.       image of a document or an extract of its contents.
  1012.  
  1013.       A given source may be the basis for many different assertions.  Thus, much of the information
  1014.       is the same for many different citations of that source, such as the publisher information; and
  1015.       yet, some of the information varies from one citation to the next, such as the page number for
  1016.       a specific item.  Consequently, the SOURCE_STRUCTURE includes a sophisticated
  1017.       mechanism for sharing general source description information that is common across multiple
  1018.       citations, while at the same time allowing more specific information to be more directly
  1019.       associated with individual citations.  All tags within the SOURCE_STRUCTURE participate in
  1020.       this approach.
  1021.  
  1022.       To implement the mechanism, the SOURCE_STRUCTURE includes a SOURce pointer that
  1023.       refers to another SOURCE_STRUCTURE containing more general information to be included
  1024.       in the citation.  This forms a chain of records, beginning within an individual or family record
  1025.       and ending in a source record that does not contain another SOURce pointer.
  1026.  
  1027.       A given tag may appear in more than one record along the chain.  In this case, the tag
  1028.       occurring in one link (source record) of the chain is said to shadow or supersede the same tag
  1029.       found in subsequent records of the chain.  A program looking for a particular tag (or tags) in
  1030.       the citation starts looking in the first record of the chain and continues looking in each
  1031.       subsequent record in the chain for the appropriate tag, succeeding when the tag is found or
  1032.       failing when the end of the chain is reached.  In effect, a complete logical source citation is
  1033.       the set of all tags of all records within the source chain, excluding shadowed tags.
  1034.  
  1035.       The chain may consist of only one SOURCE_STRUCTURE contained entirely inside an
  1036.       individual or family record, with no SOURce pointer leading out from the individual or family
  1037.       record.  More typically, the chain will begin in the individual or family record and end in an
  1038.       ordinary source description record.  Occasionally, a multiple volume source may be
  1039.       represented using a record in the middle of the chain for specific information about the
  1040.       volume.
  1041.       For example, in a multiple volume source where each volume covered a range of years, a
  1042.       volume description would contain the PERIod covered by the volume, and the more general
  1043.       description of the set of volumes would contain the PERIod covered by the entire set of
  1044.       volumes.  In assembling the complete source citation, the program would stop searching for
  1045.       the PERIod as soon as it found a PERIod tag, which in this case would be in the volume
  1046.       description.  In a multiple volume source where each volume covered a specific place as part
  1047.       of a larger grouping of places, the program would find the PLACE_STRUCTURE information
  1048.       in the intermediate volume description, and it would find the PERIod information in the final,
  1049.       more general description of the set of volumes.
  1050.  
  1051.       We encourage data entry systems to develop flexible entry screens which will prompt their
  1052.       users for information which will meet the minimum standards for citing sources.  At the
  1053.       minimum there should be an entry form for published sources and one for unpublished
  1054.       sources.  The elements below are marked if they were recommended by the National
  1055.       Genealogical Society as being a help in citing puplished (p) or unpublished (u) sources.
  1056.  
  1057. SOURCE_STRUCTURE:=  
  1058.                                /****** TYPE OF SOURCE ******/
  1059.       n  [ @XREF:SOUR@ | NULL ] SOUR [ <TEXT> | NULL ]             
  1060.          +1 [ CONT | CONC ] <TEXT>                                        {0:1}
  1061.          +1 CLAS <SOURCE_CLASSIFICATION_CODE>                             {1:1}up
  1062.          +1 EVEN  <EVENT_CLASSIFICATION_CODE>                             {0:1}
  1063.          +1 PERI <TIME_PERIOD_COVERED>                                    {0:M}up
  1064.                                /****** CITATION SPECIFIC INFO ******/
  1065.          +1 TITL [<DESCRIPTIVE_TITLE> | @XREF:SOUR@]                      {0:1}up
  1066.          +1 SOUR [ @XREF:SOUR@ | @XREF:EVEN ]                             {0:M}up
  1067.          +1 PAGE <PAGE_DESCRIPTION>                                       {0:1}up
  1068.          +1 DATE <ENTRY_RECORDED_DATE>                                    {0:1}u
  1069.          +1 CENS                                                          {0:1}
  1070.             +2 DATE <CENSUS_DATE>                                         {0:1}u
  1071.             +2 LINE <LINE_NUMBER>                                         {0:1}u
  1072.             +2 DWEL <DWELLING_NUMBER>                                     {0:1}u
  1073.             +2 FAMN <FAMILY_NUMBER>                                       {0:1}u
  1074.             +2 <<NOTE_STRUCTURE>>                                         {0:1}
  1075.                                /****** WHO CREATED IT ******/
  1076.       +1 ORIG                                                             {0:M}
  1077.             +2 NAME <ORIGINATOR_NAME>                                     {0:1}up
  1078.             +2 TYPE <ORIGINATOR_TYPE>                                     {1:1}up
  1079.             +2 <<NOTE_STRUCTURE>>                                         {0:1}
  1080.  
  1081.                                /****** PUBLICATION INFO ******/ 
  1082.          +1 PUBL                                                          {0:1}
  1083.             +2 TYPE <PUBLICATION_TYPE>                                    {1:1}up
  1084.             +2 NAME <NAME_OF_PUBLICATION>                                 {0:1}p
  1085.             +2 PUBR <PUBLISHER_NAME>                                      {0:1}p
  1086.             +2 <<ADDRESS_STRUCTURE>                                       {0:1}
  1087.             +2 DATE <PUBLICATION_DATE>                                    {0:1}up
  1088.             +2 EDTN <PUBLICATION_EDITION>                                 {0:1}p
  1089.             +2 SERS <SERIES_VOLUME_DESCRIPTION>                           {0:1}p
  1090.             +2 ISSU <PERIODICAL_ISSUE_NUMBER>                             {0:1}p
  1091.             +2 LCCN <LIBRARY_CONGRESS_CALL_NUMBER>                        {0:1}
  1092.  
  1093.                                /****** WHERE IS IT STORED ******/
  1094.          +1 <<REPOSITORY_STRUCTURE>>                                      {0:1}up
  1095.  
  1096.                                /****** IMMIGRATION/EMIGRATION ***/
  1097.             +2 NAME <NAME_OF_VESSEL>                                      {0:1}
  1098.             +2 PORT                                                       {0:1}
  1099.                +3 ARVL                                                    {0:1}
  1100.                   +4 DATE <ARRIVAL_DATE>                                  {0:1}
  1101.                   +4 PLAC <ARRIVAL_PLACE>                                 {0:1}
  1102.                +3 DPRT                                                    {0:1}
  1103.                   +4 DATE <DEPARTURE_DATE>                                {0:1}
  1104.                   +4 PLAC <DEPARTURE_PLACE>                               {0:1}
  1105.             +2 <<TEXT_STRUCTURE>>                                         {0:1}
  1106.             +2 <<NOTE_STRUCTURE>>                                         {0:1}
  1107.                                /****** SUPPORT DATA ******/
  1108.          +1 <<TEXT_STRUCTURE>>                                            {0:1}
  1109.          +1 <<MULTI_MEDIA_LINK>>                                          {0:M}
  1110.          +1 <<NOTE_STRUCTURE>>                                            {0:1}
  1111.          +1 STAT <SEARCH_STATUS>                                          {0:1}
  1112.             +2 DATE <SEARCH_STATUS_DATE>                                  {0:1}
  1113.          +1 REFS @XREF:SOUR@    /* REFERENCED SOURCE */                   {0:1}
  1114.          +1 FIDE <SOURCE_FIDELITY_CODE>                                   {0:1}
  1115.          +1 QUAY <QUALITY_OF_DATA>                                        {0:1}
  1116.  
  1117. TEXT_STRUCTURE:=
  1118.       This structure contains information from the source document.
  1119.       n  TEXT <SOURCE_TEXT>                                               {1:1} 
  1120.          +1  [ CONT | CONC ] <SOURCE_TEXT>                                {1:M}
  1121.          +1  <<NOTE_STRUCTURE>>                                           {0:1}           
  1122.  
  1123. USER_TAG_IN_CONTEXT:=
  1124.       A context structure which represents all of the superior level numbers and associated tags
  1125.       from level zero to the level of the new user tag.  All user tag names must start with and
  1126.       underscore (_).
  1127.  
  1128.       0  <OLD_TAG_1>                                                      {1:1}
  1129.          1 <OLD_TAG_2>                                                    {0:M}
  1130.             2 _<NEW_TAG>                                                  {0:M}
  1131.         
  1132.                 /* always start user tag name with an underscore (_).*/        
  1133.       For example, two new user tags are to be defined as _HOSP and _NURS and placed
  1134.       subordinate to an individual's birth.  The user tag in context would be: (Example only)
  1135.       n  INDI
  1136.          +1 BIRT
  1137.             +2 _HOSP
  1138.             +2 _NURS
  1139.  
  1140.       The resulting USER_TAG_SCHEMA, to be included in the HEADer record, would then look
  1141.       like the following:
  1142.  
  1143.       (Example only)
  1144.       n  SCHEMA
  1145.          +1 INDI
  1146.             +2 BIRT
  1147.                +3 _HOSP
  1148.                   +4 LABL <FULL_TAG_NAME>
  1149.                   +4 DEFN <USER_TAG-DEFINITION>
  1150.                   +4 ISA  <IS_A_KIND_OF_TAG>
  1151.                +3 _NURSE
  1152.                   +4 LABL <FULL_TAG_NAME>
  1153.                   +4 DEFN <USER_TAG-DEFINITION>
  1154.                   +4 ISA  <IS_A_KIND_OF_TAG>
  1155.       See User Defined Tag section at the end of chapter 2 for additional information.
  1156.  
  1157. USER_TAG_SCHEMA:=
  1158.       n  <<USER_TAG_IN_CONTEXT>>                                          {1:M}
  1159.          +m LABL <FULL_TAG_NAME>                                          {1:1}
  1160.          +m DEFN <USER_TAG_DEFINITION>                                    {1:1}
  1161.          +m ISA  <IS_A_KIND_OF_TAG>                                       {1:1}
  1162.            /*  +m represents the first subordinate level to the new user defined tag level.  (See
  1163.                example shown under the substructure definition for USER_TAG_IN_CONTEXT). */
  1164. PRIMITIVE ELEMENTS OF THE LINEAGE-LINKED FORM
  1165.  
  1166. The fields sizes are to show the minimum recommended field length within a database that is
  1167. constrained to fixed length fields.  GEDCOM lines are limited to 255 characters.  However, data of
  1168. any length can be included in GEDCOM by using the CONCatenation or CONTinuation tag to
  1169. expand a field beyond the 255 limit.  These two tags are being used to extend text type messages
  1170. rather than extending, for example, a name line.  Text lines are used in ADDR, DSCR, NOTE,
  1171. SOUR, TEXT, etc.
  1172.  
  1173. ADDRESS_LINE:=                                            {Size=1:40}
  1174.     Address information that, when combined with NAME and CONTinuation lines, meets
  1175.     requirements for sending communications through the mail.
  1176.  
  1177. AGE_VALUE:=                                               {Size=1:30}
  1178.     A number that indicates the age in years, months, and/or days.  Any labels must come after their
  1179.     corresponding number, for example; 4 yr 8 mo 10 da.  The year is required, and listed first,
  1180.     even if it is 0 (zero).
  1181.  
  1182. ANCESTRAL_FILE_NUMBER:=                                   {Size=1:8}
  1183.     A unique permanent record number of an individual record contained in the LDS Ancestral File.
  1184.  
  1185. ARRIVAL_DATE:=                                            {Size=1:90}
  1186.     <DATE_VALUE> 
  1187.     A date associated with an arrival event, such as the arrival of a ship into a port.
  1188.  
  1189. ARRIVAL_PLACE:=                                           {Size=1:120}
  1190.     <PLACE_VALUE> 
  1191.     The place from which travel terminated, such as the locality name of a port of arrival, such as
  1192.     Ellis Island, New York, New York.
  1193.  
  1194. ASSOCIATION_DESCRIPTOR:=                                  {Size=1:90}
  1195.     A word or phrase that describes the association between this person and another person identified
  1196.     by a pointer. (For example, n ASSO great grandfather @XREF:SUBM@ would be read, this
  1197.     person is a great-grandfather of the person defined in the submitter record.)
  1198.  
  1199. AUXILLARY_FILE_REFERENCE:=                                {Size=1:30}
  1200.     A full file reference to the auxillary data to be linked to the GEDCOM context.
  1201.  
  1202. AUXILLARY_SET_FORMAT:=                                    {Size=1:10}
  1203.    [ OLE | GIF | TIF | WPG | etc. ]
  1204.     Indicates the format of the data that is being linked to the GEDCOM context.  This will allow
  1205.     the GEDCOM processor to determine whether they are able to process the auxillary data. The
  1206.     auxillary file should contain a header record with data required, by the indicated format, to
  1207.     process the file data.
  1208.  
  1209. CALENDAR_ESCAPE_SEQUENCE:=                                {Size=4:15}   
  1210.     [ @#DHEBREW@ | @#DROMAN@ | @#DFRENCH R@ | @#DGREGORIAN@ |
  1211.       @#DJULIAN@ | @#DUNKNOWN@ ]
  1212.     An escape sequence that allows dates from one of the indicated calendars to be represented.  The
  1213.     default calendar is the Gregorian calendar.
  1214. CASTE_NAME:=          {Size=1:90}
  1215.     A name assigned to a particular group that this person was associated with, such as a particular
  1216.     racial group, religious group, or a group with an inherited status.
  1217.  
  1218. CAUSE_OF_DEATH:=                                          {Size=1:90}
  1219.     The cause of death of this person. This should be the same cause as listed on the death
  1220.     certificate if known.  (A medical history structure may be developed for a future GEDCOM
  1221.     release.)
  1222.  
  1223. CEMETERY_NAME:=                                           {Size=1:90}
  1224.     The name of the cemetery where a person was buried.
  1225.  
  1226. CHANGE_DATE:=                                             {Size=10:11}
  1227.     <DATE_EXACT>
  1228.     The date that this data was last changed.
  1229.  
  1230. CHARACTER_SET:=                                           {Size=1:8}
  1231.     A code value that represents the character set to be used to interpret this data.  The default
  1232.     character set is ANSEL which includes ASCII as a subset.  UNICODE is also will be allowed. 
  1233.     See chapter 3.
  1234.  
  1235. CHILD_FAMILY_EVENT_DESCRIPTOR:=                           {Size=1:90} 
  1236.     A word or phrase that describes or modifies the adoption event being reported.
  1237.  
  1238. CONCATENATED_DATA:=                                       {Size=1:247}
  1239.     Adds new data to the end of the data in the preceding context.
  1240.  
  1241. CONTACT_PERSON:=                                          {Size=1:120}  
  1242.     <PERSONAL_NAME>
  1243.     The name of the person to whom communications should be addressed.
  1244.  
  1245. CONTINUED_DATA:=                                          {Size=1:247}
  1246.     A new line which logically is included in the preceding line.  This may be used in specified
  1247.     situations where the value length exceeds the maximum allowed length for the line.
  1248.                                                                              
  1249. COPYRIGHT_STATEMENT:=                                     {Size=1:90}
  1250.     A copyright statement needed to protect the rights of the owner of this data.
  1251.  
  1252. CORPORATE_NAME:=                                          {Size=1:90}
  1253.     The company, corporate or government agency name.
  1254.  
  1255. COUNT_OF_CHILDREN:=                                       {Size=1:3, Type=NUMBER}
  1256.     The number of children of this individual from all marriages or of this family, regardless of
  1257.     whether the associated children are represented in the GEDCOM file.
  1258.                                                                               
  1259. COUNT_OF_MARRIAGES:=                                      {Size=1:3, Type=NUMBER}
  1260.     The number of different families that this person was known to have been a member of as a
  1261.     spouse or parent, regardless of whether the associated families are represented in the GEDCOM
  1262.     file.
  1263.  
  1264. DATE_DUAL:=           {Size=1:90}
  1265.     <DATE_REGULAR/<YEAR_ALTERNATIVE> 
  1266.     A date which shows the possible date alternatives arising from a calendar change, for example,
  1267.     15 Dec 1752/3. 
  1268.  
  1269. DATE_EXACT:=          {Size=10:11}
  1270.     <DAY> <MONTH> <YEAR>
  1271.     A formatted date with one space between the day and the month and one space between the
  1272.     month and the year.
  1273.  
  1274. DATE_MODIFIER:=                                           {Size=3:15}
  1275.     [ ABT | AFT | BEF | EST | <CALENDAR_ESCAPE_SEQUENCE>]
  1276.     Qualifies the meaning of a date.
  1277.        ABT = About
  1278.        AFT = After
  1279.        BEF = Before
  1280.        EST = Estimated
  1281.  
  1282. DATE_PHRASE:=         {Size=1:90}
  1283.     <text>
  1284.     Any statement offered as a date when the specific year is not known, but which gives
  1285.     information about when an event occurred. 
  1286.  
  1287. DATE_RANGE:=          {Size=17:31}
  1288.     [ BET <DATE_REGULAR> AND <DATE_REGULAR> ]
  1289.  
  1290. DATE_REGULAR:=                                            {Size=4:35}
  1291.     [ <DATE_MODIFIER | blank ] [ <DATE_EXACT> | <MONTH> <YEAR> |
  1292.     <YEAR> ]
  1293.     
  1294. DATE_VALUE:=          {Size=1:90}
  1295.     [ <DATE_REGULAR> | <DATE_PHRASE> | <DATE_RANGE> |
  1296.     <DATE_WITH_BC> |
  1297.      <DATE_DUAL> | <DATE_MODIFIER> <DATE_REGULAR> ]
  1298.     Examples:
  1299.        15 JUN 1990
  1300.        2 days after easter 1790
  1301.        BET NOV 1830 AND 25 DEC 1830
  1302.        600 B.C.
  1303.        ABT 1 JAN 1440
  1304.        @#DFRENCH R@28 NIVOSE AN09
  1305.  
  1306. DATE_WITH_BC:=                                            {Size=1:90}
  1307.     [ <DATE_PHRASE> <YEAR> B.C. ]
  1308.     A date of an event that occurred before Christ.
  1309.  
  1310. DAY:=                                                     {Size=1:2, Type=NUMBER}
  1311.     dd
  1312.     Day of the month, where dd is a numeric digit whose value is within the valid range of the days
  1313.     for the associated month.
  1314. DEPARTURE_DATE:=                                          {Size=1:90}
  1315.     <DATE_VALUE> 
  1316.     A date associated with an departure event, such as the departure of a ship from a port.
  1317.  
  1318. DEPARTURE_PLACE:=                                         {Size=1:120}
  1319.     <PLACE_VALUE> 
  1320.     The place from which travel began, such as the locality name of a port of departure, such as
  1321.     Pier 37, San Francisco, California.
  1322.  
  1323. DESCRIPTIVE_TITLE:=                                       {Size=1:247}      
  1324.     A descriptive title of the information source, such as a description of:   
  1325.        *        A title of an article published in a periodical.                       
  1326.        *        A letter including the date, the sender and the receiver.
  1327.        *        A transaction between a buyer and seller including their names and date of
  1328.                 transaction.       
  1329.        *        A Family Bible containing genealogical information including past and present
  1330.                 owners and a physical description of the book.        
  1331.        *        A personal interview.                                 
  1332.  
  1333. DIVORCE_DESCRIPTOR:=                                      {Size=1:90}
  1334.     A word or phrase that commonly describes the kind of separation, such as  "divorce" or
  1335.     "separated", that took place between husband and wife.  The separation descriptor should use the
  1336.     same word or phrase and in the same language, whenever possible, that was used by the
  1337.     recorder of the event.
  1338.  
  1339. DIV_EVNT_TAG:=                                            {Size=3:4}
  1340.     [ ANUL | DIV | DIVF ]     (See Appendix B for additional Tags)
  1341.     A family event tag which describes the event of separation.
  1342.  
  1343. ENTRY_RECORDING_DATE:=                                    {Size=1:90}
  1344.     <DATE_VALUE>
  1345.     The date that the entry was entered into the source record by the recorder.
  1346.  
  1347. ESCAPE_TO_AUXILLARY_PROCESSING:=                          {Size=1:30}
  1348.    [ @#A<AUXILLARY_FILE_REFERENCE> <AUXILLARY_SET_FORMAT>
  1349.     An escape sequence which allows for alternate data formats to be linked to a specific context
  1350.     within the GEDCOM file.  The linked data referenced is for special processing and is tied to the
  1351.     context in which the escape was issued.  For instance, data specific to Window's Object linking
  1352.     and embedding servers would be referenced in this manner.  See Chapter 6, "Microsoft
  1353.     Windows Programmer's Reference" for the format of the standard OLE data stream.  This
  1354.     allows the transmission of images, sounds, or other auxillary processing associated with the
  1355.     enclosing context.  The format of the escape sequence has only been designed for including data
  1356.     by referencing a specific file name.  This means that there will be an unique auxillary data file
  1357.     for each link.  In the future we may adopt a method of including all of the auxillary data in a
  1358.     single auxillary transmission file.  Other auxillary process formats may also be defined in later
  1359.     GEDCOM versions.
  1360.  
  1361. EVENT_CLASSIFICATION_CODE:=                               {Size=1:90}
  1362.     [ <IND_EVNT_TAG> | <EVENT_DESCRIPTOR> ]
  1363.     A code that classifies the principal event that caused this source record to be created.
  1364. EVENT_DESCRIPTOR:=                                        {Size=1:90}
  1365.     A descriptor that should be used whenever the EVEN tag is used to define the event being cited. 
  1366.     For example, if the event was a purchase of a residence, the EVEN tag would be followed by
  1367.     the phrase "Purchased Residence."   When this descriptor is used with any of the defined event
  1368.     tags, it modifies the basic definition of the associated tag.  For example the BIRT tag could be
  1369.     used in connection with an EVENT_DESCRIPTOR of "Stillborn" to modify the birth event as a
  1370.     stillborn birth.  An EVENT_DESCRIPTOR of "DEAD" shows a person is dead but the death
  1371.     date is not known.  The event descriptor should use the same word or phrase and in the same
  1372.     language, when possible, that was used by the recorder of the event.  Systems that display data
  1373.     from the GEDCOM form should be able to display the descriptor value in their screen or printed
  1374.     output.
  1375.  
  1376. EVENT_TAG:=           {Size=3:4}
  1377.      [ <IND_EVNT_TAG> | <FAM_EVNT_TAG> | <DIV_EVNT_TAG> ]   
  1378.     An event tag chosen from the tags identifying either individual or family events, including the
  1379.     EVEN tag with an event descriptor.
  1380.  
  1381. FAMILY_EVENT_DESCRIPTOR:=                                 {Size=1:90}
  1382.     A word or phrase that best describes the circumstances that created this family.  The marriage
  1383.     descriptor should use the same word or phrase and in the same language, when possible, that
  1384.     was used by the recorder of the event. Possible descriptor values include "Childbirth-
  1385.     unmarried," "Common Law," "Tribal Custom," for example.  Systems that display data from
  1386.     the GEDCOM form should be able to display the descriptor value in their screen or printed
  1387.     output. (See also <DIV_EVNT_TAG>.)
  1388.  
  1389. FAM_EVNT_TAG:=                                            {Size=3:4}
  1390.     [ CENS | MARR | MARB | MARC | MARL | MARS | ENGA | EVEN ]
  1391.                 (See Appendix B for additional Tags)
  1392.     An event tag indicating the reason for defining a family.
  1393.  
  1394. FILE_NAME:=                                               {Size=1:90}
  1395.     The name of the GEDCOM transmission file on the source operating system.  It includes the
  1396.     path, file name, and file extension.  The path may optionally include the drive letter.
  1397.  
  1398. FILM_ITEM_IDENTIFICATION:=                                {Size=1:90}
  1399.     A particular book or unit of material that may have been filmed with other books or units on the
  1400.     same microfilm.  The convention used in the Family History Department microfilms is to
  1401.     include a separator frame with a sequential item number to separate multiple books on a single
  1402.     film.
  1403.  
  1404. FULL_TAG_NAME:=                                           {Size=1:15}
  1405.     The long name of a user defined GEDCOM tag. For example, HOSP tag would have a long
  1406.     name of HOSPITAL. This name should be a name that could be used as a field label for reports
  1407.     and screens.  The name may include underscore characters (_).
  1408.  
  1409. GEDCOM_FORM:=                                             {Size=1:15}
  1410.     [ LINEAGE-LINKED | (others to be registered) ]
  1411.     The GEDCOM form used to construct this transmission.
  1412.  
  1413. GOVERNMENT_AGENCY:=                                       {Size=1:90}
  1414.     The name of the branch of government associated with this event or data.
  1415.  
  1416. IND_EVNT_TAG:=                                            {Size=3:4}
  1417.     [ ADOP | BIRT | BAPM | BARM | BASM | BLES | BURI | CENS | CHR  | CHRA |
  1418.       CONF | DEAT | EVEN | EMIG | GRAD | IMMI | MARR | NATU | ORDN | RETI |
  1419.       PROB | WILL ]
  1420.  
  1421.     An individual event tag.  The EVEN tag must be followed by a TYPE and an
  1422.     <EVENT_DESCRIPTOR>. The <EVENT_DESCRIPTOR> is optional for the defined event
  1423.     tags, for example: 
  1424.                 1 EVEN
  1425.                 2 TYPE Farley Family Reunion
  1426.                 1 BIRT
  1427.                 2 TYPE illegitimate
  1428.  
  1429.     (See Appendix A for tag definitions or see Appendix B for proposed Tags.  These proposed tags
  1430.     have not been standardized.  They may be used as a value for the TYPE tag under the EVEN
  1431.     tag or under the appropriate approved event tags.  Appropriate means that the event should be
  1432.     processed the same as the selected superior tag)
  1433.  
  1434. INDI_TITLE:=                                              {Size=1:90}
  1435.     A formal designation used by an individual in connection with the individuals name, for
  1436.     example, (Captain) John Smith. 
  1437.  
  1438. INFORMANTS_NAME:=                                         {Size=1:90}
  1439.     <PERSONAL_NAME>
  1440.     The name of a person who contributed evidence information.
  1441.  
  1442. INTERVIEWERS_NAME:=                                       {Size=1:90}
  1443.     <PERSONAL_NAME>
  1444.     The name of the person who conducted the interview for information.
  1445.  
  1446. IS_A_KIND_OF_TAG:=                                        {Size=1:25}
  1447.     [ <LANGUAGE_TABLE> ]
  1448.     The human language in which the data in the transmission is normally read or written.  It is used
  1449.     primarily by programs to select language-specific sorting sequences and phonetic name matching
  1450.     algorithms.
  1451.  
  1452. LANGUAGE_PREFERENCE:=                                     {Size=1:90}
  1453.     [ <LANGUAGE_TABLE> ]
  1454.     The language in which a person prefers to communicate.  Multiple language preference is shown
  1455.     by using multiple occurrences in order of priority.
  1456.  
  1457. LANGUAGE_TABLE:=                                          {Size=1:25}
  1458.     A table of valid language codes.  This table of valid languages may be found in the
  1459.     Encyclopedia Britannica 1989 Book of the Year.
  1460.  
  1461. LDS_CHILD_SEALING_DESCRIPTOR:=                            {Size=1:20}
  1462.     <LDS_ORDINANCE_DESCRIPTOR>
  1463.     A descriptor that describes the disposition of this ordinance.  The appropriate descriptor is one
  1464.     of the choices defined by <LDS_ORDINANCE_DESCRIPTOR>. 
  1465.  
  1466. LDS_FAM_ORD_DESCRIPTOR:=                                  {Size=1:20}
  1467.     <LDS_ORDINANCE_DESCRIPTOR>
  1468.     A descriptor that describes the disposition of this ordinance.  The appropriate descriptor is one
  1469.     of the choices defined by <LDS_ORDINANCE_DESCRIPTOR>. 
  1470.  
  1471. LDS_INDI_ORD:=        {Size=3:4}
  1472.     [ BAPL | CONL | WAC  | ENDL ]
  1473.     A tag that represents an individual's religious event associated with The Church of Jesus Christ
  1474.     of Latter-day Saints.   (See Appendix A for a definition of these tags.)
  1475.  
  1476. LDS_INDI_ORD_DESCRIPTOR:=                                 {Size=1:90}
  1477.     <LDS_ORDINANCE_DESCRIPTOR>
  1478.     A descriptor that specifies the disposition of this ordinance.  The appropriate descriptor is one of
  1479.     the choices defined by <LDS_ORDINANCE_DESCRIPTOR>. 
  1480.  
  1481. LDS_ORDINANCE_DESCRIPTOR:=                                {Size=1:20}
  1482.     [ BIC | CANCELED | COMPLETED | DNS | DONE | INFANT | STILLBORN |
  1483.     SUBMITTED ]
  1484.     A code indicating the status of an LDS ordinance.
  1485.     BIC       =       This person was born in the covenant, meaning that he or she automatically
  1486.                       receives the blessing of 'child to parent' sealing.
  1487.     COMPLETED=        This ordinances has been completed but the date is not known.
  1488.     DNS       =       This record is not being submitted for this temple ordinances.
  1489.     DONE      =       This ordinance has been completed but the date is not known.
  1490.     INFANT    =       This person died before eight years old.
  1491.     STILLBORN =       This person was stillborn.
  1492.     SUBMITTED =       This ordinance was previously submitted.
  1493.  
  1494. LIBRARY_CONGRESS_CALL_NUMBER:=                            {Size=1:20}       
  1495.     The call number assigned to this item by the U.S. Library of Congress. 
  1496.  
  1497. MANUAL_FILING_IDENTIFICATION:=                            {Size=1:90}
  1498.     A description of where the source is manually filed at this repository or personal collection. 
  1499.     Personal genealogical collections should be organized and filed so that items can be specifically
  1500.     identified and retrieved.  For example, "Probate file Drawer 83, File D, Number 18", or "Box
  1501.     3, Smith Folder".
  1502.  
  1503. MARITAL_STATUS:=                                          {Size=1:20}
  1504.     [ D | S | W | _<TEXT> ]
  1505.     The marital status at the time of the associated event.  Status values are:
  1506.        D =      Single but legally Divorced at time of event.
  1507.        M =      Married at time of event.
  1508.        S =      Single, never married at time of event.
  1509.        W =      Single because of the death of a spouse.
  1510.        _ =      If other information about marital status is to be shown add the appropriate text
  1511.                 preceded by an underscore "_".
  1512.  
  1513. MEDIA_TYPE:=          {Size=1:15}
  1514.     [ AUDIO | BOOK | CARD | ELECTRONIC | FICHE | FILM | MAGAZINE |
  1515.     MANUSCRIPT | MAP | NEWSPAPER | PHOTO | TOMBSTONE | VIDEO ]
  1516.     A code, selected from one of the media classifications choices above that indicates the type of
  1517.     material in which the referenced source is stored.
  1518.  
  1519. MONTH:=                                                   {Size=3:3}
  1520.     [ JAN | FEB | MAR | APR | MAY | JUN |
  1521.       JUL | AUG | SEP | OCT | NOV | DEC ]
  1522.     A month name abbreviation selected from the choices above, used in forming dates.
  1523.  
  1524. NAME_OF_SOURCE_DATA:=                                     {Size=1:90}
  1525.     The name of the electronic data source that was used to obtain the data in this transmission.  For
  1526.     example, the data may have been obtained from a CD-ROM disc that was named "U.S. 1880
  1527.     CENSUS CD-ROM vol. 13."
  1528.  
  1529. NAME_OF_VESSEL:=                                          {Size=1:90}
  1530.     A name of the ship, air ship, or commercial vehicle used for travel, immigration, emigration,
  1531.     etc.
  1532.  
  1533. NATIONALITY:=         {Size=1:90}
  1534.     The person's national origin in common usage.  Examples: Irish, Native American, Swede, and
  1535.     so forth.
  1536.  
  1537. NATIONAL_ID_NUMBER:=                                      {Size=1:30}
  1538.     A nationally-controlled number assigned to an individual.  Commonly known national numbers
  1539.     should be assigned their own tag, such as SSN for U.S. Social Security Number.  The use of the
  1540.     IDNO tag requires a subordinate TYPE tag to identify what kind of number is being stored. For
  1541.     example:
  1542.        n  IDNO 43-456-1899
  1543.          +1 TYPE Canadian Health Registration 
  1544.  
  1545. NEW_TAG:=             {Size=3:15}
  1546.     A user defined tag that is contained in the GEDCOM current transmission.  This tag must be
  1547.     defined within the SCHEMA context in the HEADer record and its name must begin with an
  1548.     underscore (_).  The SCHEMA context defines the data associated with this new tag. (See tags
  1549.     LABL, DEFN, and ISA).
  1550.  
  1551. NULL:=                                                    {Size=0:0}
  1552.     convention that indicates the absence of any characters in the value including
  1553.     A  the null character (0x00) which is prohibited.
  1554.  
  1555. OCCUPATION:=                                              {Size=1:90}
  1556.     The kind of activity that an individual does for a job, profession, or principal activity.
  1557.  
  1558. OLD_TAG_1:=                                               {Size=3:15}
  1559.     This is any tag defined by the GEDCOM standard and is used in the SCHEMA context of the
  1560.     HEADer record to show the context in which a new user defined tag is being used.  This tag
  1561.     always represents a tag which was used at level 0.
  1562.  
  1563. OLD_TAG_2:=                                               {Size=3:15}
  1564.     This is any tag defined by the GEDCOM standard and is used in the SCHEMA context of the
  1565.     HEADer record to show the context in which a new user defined tag is being used.  Old_TAG_2
  1566.     represents any tag at any level between level 1 and the level in which the new user defined tag
  1567.     resides. For example, 
  1568.    n SCHEMA
  1569.     +1 INDI  (zero level)
  1570.        +2 BURI
  1571.          +3 PLAC
  1572.                 +4 CEME
  1573.                   +5 _PLOT (new user tag)
  1574.  
  1575. ORD_BY_PATRON_CODE:=                                      {Size=1:1}
  1576.     [ Y | N ]
  1577.     A code that identifies whether the patron will provide proxies for the cleared ordinances
  1578.     specified by the associated tag.
  1579.        Y = Patron will provide proxies for the associated cleared ordinance.
  1580.        N = Temple is to provide proxies for the associated cleared ordinance.
  1581.  
  1582. ORIGINATOR_NAME:=                                         {Size=1:120}
  1583.     [ <PERSONAL_NAME> | <CORPORATE_NAME> ]
  1584.     The name of the person or organization that created this source.
  1585.  
  1586. ORIGINATOR_TYPE:=                                         {Size=3:15}
  1587.     [ AUTHOR | COMPILER | TRANSCRIBER | ABSTRACTOR | EDITOR |
  1588.       INFORMANT | INTERVIEWER | GOVERNMENT | BUSINESS | ORGANIZATION ]
  1589.     A classification of the type of the person or entity that created this source.
  1590.  
  1591. PAGE_DESCRIPTION:=                                        {Size=1:90}
  1592.     A field that identifies the page within the source.  This may be a page number range, a specific
  1593.     page number, or another way of defining how to find the specified information within the
  1594.     source.
  1595.  
  1596. PERIODICAL_ISSUE_NUMBER:=                                 {Size=1:90}
  1597.     The number or description of the specific periodical publication.
  1598.  
  1599. PERMANENT_RECORD_FILE_NUMBER:=                            {Size=1:18}    
  1600.     <REGISTERED_RESOURCE_IDENTIFIER>:<RECORD_IDENTIFIER>
  1601.     The record number that uniquely identifies this record within a registered network resource. 
  1602.     The number will be usable as a cross-reference pointer. The use of the colon (:) is reserved to
  1603.     indicate the separation of the 'registered resource identifier'(precedes the colon) and the unique
  1604.     'record identifier' within that resource (follows the colon).  In cases where the colon is used,
  1605.     implementations that check pointers should not expect to find a matching cross reference
  1606.     identifier in the transmission but would find them in the indicated database within a network. 
  1607.     Making resource files available to a public network is a future implementation.
  1608.  
  1609. PERSONAL_NAME:=                                           {Size=1:120}
  1610.     [
  1611.      <TEXT> |
  1612.     /<TEXT>/ |
  1613.      <TEXT> /<TEXT>/ |
  1614.     /<TEXT>/ <TEXT> |
  1615.      <TEXT> /<TEXT>/ <TEXT>
  1616.     ]
  1617.     The surname of an individual, if known, is enclosed between two slash (/) characters. The order
  1618.     of the name parts should be the order that the person would customarily have used when giving
  1619.     it to a recorder. If part of name is illegible, that part is indicated by ... (ellipses).
  1620.  
  1621.     Examples:
  1622.        William Lee
  1623.        /Parry/
  1624.        William Lee /Parry/
  1625.        William /Lee/ Parry
  1626.        William Lee /Pa.../
  1627.  
  1628. PHONE_NUMBER:=                                            {Size=1:25}
  1629.     A phone number.
  1630.  
  1631. PHYSICAL_DESCRIPTION:=                                    {Size=1:247}
  1632.     A comma delimited, unstructured list of the attributes that describe the physical characteristics of
  1633.     a person, place, or object.
  1634.     Example:
  1635.        1 DSCR Hair Brown, Eyes Brown, Height  5 ft 8 in
  1636.  
  1637. PLACE_VALUE:=         {Size=1:120}
  1638.     [
  1639.     <TEXT> |                                                                 
  1640.     <TEXT>, <PLACE_VALUE>                                                    
  1641.     ]                                                                          
  1642.     The jurisdictional name of the place where the event took place. Jurisdictions are separated by
  1643.     commas, that is, town, county, state or village, parish, country.  Receiving systems cannot
  1644.     assume that the nth locality position is necessarily a specific level of jurisdiction.  Some systems
  1645.     may include a PLAC context in the HEADer record which will specify the jurisdictional levels
  1646.     to the place names.  Missing intermediate jurisdictions is represented by adjacent placeholder
  1647.     commas.  If FORM value within the PLACe context of the HEADer record is present, then all
  1648.     levels of jurisdiction must be accounted in this way.  For example if the following was included
  1649.     in the header record:
  1650.        0 HEAD
  1651.         1 PLAC
  1652.          2 FORM city, county, state, country
  1653.     Then each place name would be expected to account for the four levels by using appropriately
  1654.     placed commas.
  1655.  
  1656.     A FORM tag showing a change to this default assumption shown in the HEADer record can be
  1657.     used subordinate to an individual place structure to show the variant jurisdictional levels.
  1658.  
  1659.     A place of origin that is not necessarily a birth place is shown by preceding the place name with
  1660.     the word "of."  Missing or illegible characters within a place name are indicated by ...
  1661.     (ellipses).
  1662.  
  1663. POSSESSIONS:=                                             {Size=1:247}
  1664.     A list of possessions (real estate or other property) belonging to this individual, separated by
  1665.     commas.
  1666.  
  1667. PRODUCT_NAME:=                                            {Size=1:90}
  1668.     The name of the software product that produced this transmission.
  1669.  
  1670. PUBLICATION_DATE:=                                        {Size=1:90}
  1671.     <DATE_REGULAR>
  1672.     The date this source was published or compiled.
  1673.  
  1674. PUBLICATION_EDITION:=                                     {Size=1:90}
  1675.     A description of the specific version of the publication which is being referenced.
  1676.  
  1677. PUBLICATION_NAME:=                                        {Size=1:90}
  1678.     The name of a publication such as a book, pamphlet, periodical, newspaper, or other
  1679.     monographic publication.
  1680.  
  1681. PUBLICATION_PLACE:=                                       {Size=1:120}
  1682.     <PLACE_VALUE>
  1683.     The name of the place (city, state) where an item was published or the location of the publisher's
  1684.     main office.
  1685.  
  1686. PUBLICATION_TYPE:=                                        {Size=4:12}
  1687.  [ BOOK | PERIODICAL | NEWSPAPER | UNPUBLISHED | ELECTRONIC ]
  1688.  
  1689. PUBLISHER_NAME:=                                          {Size=1:90}
  1690.     The name of the publisher of the referenced publication.
  1691.  
  1692. QUALITY_OF_DATA:=                                         {Size=1:1, Type=NUMBER}
  1693.     [ 0 | 1 | 2 | 3 ]
  1694.     The submitter's assessment of the reliability of the information for the associated fact:       
  1695.       0 = Unreliable evidence or data was estimated.                          
  1696.       1 = Direct or primary evidence with some question of reliability        
  1697.           or potential for bias for example, an autobiography).                     
  1698.       2 = Secondary evidence.                                                 
  1699.       3 = Direct and primary evidence used, or by dominance of the evidence.   
  1700.  
  1701. RECORD_IDENTIFIER:=                                       {Size=1:18}
  1702.     An identification number assigned to each record within a specific data base.  If this identifier is
  1703.     associated with a preceding colon (:), then it is the record number within the registered resource
  1704.     identified by the data that precedes the (:) else it is a specific reference to a record within the
  1705.     current database if no registered resource identifier precedes the (:).  If the colon is not present
  1706.     it is the identification of a record within the current GEDCOM transmission file.
  1707.  
  1708. REGISTERED_RESOURCE_IDENTIFIER:=                          {Size=1:18}
  1709.     This is an identifier assigned to a resource data base which is available through access to an
  1710.     available network. (Future plans.)
  1711.  
  1712. RELATIONSHIP_ROLE_TAG:=                                   {Size=1:90}       
  1713.    [ BROT | CHIL | FATH | HEIR | HUSB | MOTH | PARE | PHUS | PWIF | SIBL |
  1714.      SIST | WIFE ]  
  1715.  
  1716. RELIGIOUS_AFFILIATION:=                                   {Size=1:90}
  1717.     A name of the religion with which this person or record was affiliated.
  1718.  
  1719. RELIGIOUS_NAME:=                                          {Size=1:120}
  1720.     A name given to a person to be used in connection with a religion.
  1721.  
  1722. REPOSITORY_NAME:=                                         {Size=1:90}
  1723.     The official name of the archive in which the stated source material is stored.
  1724.  
  1725. ROLE_DESCRIPTOR:=                                         {Size=1:90}       
  1726.     A word or phrase that identifies the role of each person in the event being described. This
  1727.     should be the same word or phrase, and in the same language, that the recorder used to define
  1728.     the role in the actual record. This is used in connection with the ROLE_TAG.
  1729.  
  1730. ROLE_TAG:=                                                {Size=1:20}       
  1731.    [ BUYR | CHIL | FATH | GODP | HDOH | HDOG | HEIR | HFAT | HMOT | HUSB |
  1732.      INFT | LEGA | MEMBER| MOTH | OFFI | PARE | PHUS | PWIF | RECO | REL  |
  1733.      ROLE | SELR | TXPY | WFAT | WIFE | WITN | WMOT | INDI ]  
  1734.     A tag that indicates the role of the individuals mentioned in a source event record.  If the above
  1735.     list does not include the role being cited, use the ROLE_TAG followed by a
  1736.     ROLE_DESCRIPTOR to define the role. (See appendix A for the definition of these tags and
  1737.     Appendix B for additional ROLEs which have been proposed as GEDCOM tags).  Names of
  1738.     individuals mentioned in the event but their role was not mentioned, should be identified by
  1739.     using the INDI role tag.  Any associations between others of known roles and this individual can
  1740.     be shown by using the ASSOciation pointer.
  1741.  
  1742. SCHOLASTIC_ACHIEVEMENT:=                                  {Size=1:247}
  1743.     A description of a scholastic or educational achievement or pursuit.
  1744.  
  1745. SEARCH_STATUS:=                                           {Size=1:90}
  1746.     [ ACTIVE | FOUND | NO | ORDERED | PLANNED |  PROVED ]
  1747.     A field that shows the research status with respect to the cited source. Where:
  1748.     ACTIVE      =     This source is currently being searched.         
  1749.     FOUND       =     Part or all of the expected information has been found.
  1750.     NO          =     This source is no longer in use because the information could not be found.
  1751.     ORDERD      =     A request for this source has been sent to the Repository.   
  1752.     PLANNED=          This source is to be examined.                   
  1753.     PROVED      =     This source has been reconciled with the data in this record.
  1754.                                                                               
  1755. SEARCH_STATUS_DATE:=                                      {Size=1:90}
  1756.     <DATE_EXACT>
  1757.     The date on which the current SEARCH_STATUS was set.
  1758.  
  1759. SERIES_VOLUME_DESCRIPTION:=                               {Size=1:247}
  1760.     A description of a successive publication.  The description should identify the timing of the
  1761.     publication, for example, Spring, Summer, Fall, Winter.  The description should also state the
  1762.     volume number of periodicals or of multi-volume books.
  1763.  
  1764. SEX_VALUE:=                                               {Size=1:7}
  1765.     A code that indicates the sex of the individual:
  1766.      M = Male                                                               
  1767.      F = Female
  1768.  
  1769. SIGNATURE_INFO:=                                          {Size=1:90}  
  1770.     A description of the capabilities of this person to sign documents, the symbol used in signing, 
  1771.     did they know how to sign,  did they use a model to produce a signature.
  1772.  
  1773. SITE_NAME:=                                               {Size=1:90}
  1774.     The name of a specific site associated with an event, address, or place.
  1775.  
  1776. SOCIAL_SECURITY_NUMBER:=                                  {Size=9:11}
  1777.     A social security identification number assigned to this person.
  1778.  
  1779. SOURCE_CALL_NUMBER:=                                      {Size=1:90}
  1780.     An identification number used to file and retrieve items from the holdings of a repository.
  1781.  
  1782. SOURCE_CLASS_DESCRIPTOR:=                                 {Size=1:25}       
  1783.     A descriptive word or phrase that classifies the type of source being cited.  This descriptor is
  1784.     used only when none of the classifications defined under the
  1785.     <SOURCE_CLASSIFICATION_CODE> fit this source type.  Systems that display data from
  1786.     the GEDCOM form should be able to display the descriptor value in their screen or printed
  1787.     output.
  1788.  
  1789. SOURCE_CLASSIFICATION_CODE:=                              {Size=7:90}
  1790.     [ BOOK | CENSUS | CHURCH | COURT | HISTORY | INTERVIEW | JOURNAL |
  1791.       LAND | LETTER | MILITARY | NEWSPAPER | PERIODICAL | PERSONAL |
  1792.       RECITED | TRADITION | VITAL | OTHER!<SOURCE_CLASS_DESCRIPTOR> ]
  1793.  
  1794.     A code which classifies the source which contained the evidence data.  Where:
  1795.     BOOK           =  A published work including biographies and genealogies.
  1796.     CENSUS         =  A official census. 
  1797.     CHURCH         =  A church record.
  1798.     COURT          =  A record from a court, both criminal and civil.
  1799.     HISTORY        =  A published historical account. 
  1800.     INTERVIEW      =  An interview.
  1801.     JOURNAL        =  A personal record or diary.
  1802.     LAND           =  A record of land holdings or transactions, both federal and state.
  1803.     LETTER         =  A letter or other written communication.
  1804.     MILITARY       =  A military record.
  1805.     NEWSPAPER      =  A newspaper account.
  1806.     PERIODICAL     =  A work that is published at certain intervals, such as monthly, quarterly, or
  1807.                       yearly.
  1808.     PERSONAL       =  A source that was compiled from accounts given from a person's memory.
  1809.     RECITED        =  A recited genealogy, such as a tribal or clan genealogy.
  1810.     TRADITION      =  A source that was compiled from accounts communicated by word-of-mouth
  1811.                       from one generation to another.
  1812.     VITAL          =  A vital record created by a government agency of vital records such as births,
  1813.                       marriages, and divorces.
  1814.     OTHER!         =  Other sources can be identified by using (OTHER!) followed by
  1815.                       <SOURCE_CLASS_DESCRIPTOR>.
  1816.     Systems that display data from the GEDCOM form should be able to display the descriptor value
  1817.     in their output.
  1818.  
  1819. SOURCE_FIDELITY_CODE:=                                {Size=7:17}
  1820.     [ ORIGINAL | PHOTOCOPY | TRANSCRIPT | EXTRACT ]
  1821.     A code is a selected from the above choices that provides an assessment of the fidelity (the
  1822.     exactness) of this source material.
  1823.       ORIGINAL         =    This source is the original record being cited.
  1824.       PHOTOCOPY        =    This source is a photocopy of the original record. 
  1825.       TRANSCRIPT       =    This source is a complete transcription of the original record.
  1826.       EXTRACT          =    This source is an abridgement, subset, and/or interpretation.
  1827.  
  1828. SOURCE_FILM_NUMBER:=                                      {Size=1:15}
  1829.     A unique number assigned by the repository to identify the specific microfilm containing
  1830.     information about the event of interest.
  1831.  
  1832. SOURCE_JURISDICTION_PLACE:=                               {Size=1:120}
  1833.     <PLACE_VALUE>
  1834.     The name of the lowest jurisdiction that encompasses all lower-level places named in this source. 
  1835.      For example, "Franklin, Idaho" would be used as a source jurisdiction place for events
  1836.     occurring in the various towns within Franklin county but "Idaho" would be used as a source
  1837.     jurisdiction place if the source records referenced other counties in Idaho besides Franklin
  1838.     county.
  1839.  
  1840. SOURCE_TEXT:=         {Size=1:247}                        
  1841.     <TEXT>
  1842.     A verbatim copy of any description contained within the source.  This indicates notes that are
  1843.     actually contained in the source document, not the submitter's opinion about the source. 
  1844.  
  1845. SUBMITTER_TEXT:=                                          {Size=1:247}
  1846.     Comments or opinions from the submitter.
  1847.  
  1848. SYSTEM_NAME:=                                             {Size=1:20}
  1849.     The name of the sending or receiving GEDCOM-compatible product.  The system name for the
  1850.     sending system was obtained when the product was registered as a GEDCOM-compatible
  1851.     product.  All GEDCOM transmissions must be so identified.  The system name used with the
  1852.     DESTination tag should be:
  1853.       *   "ANSTFILE" when sending to the ancestral file.
  1854.       *   "TempleReady" when submitting for temple ordinances.
  1855.       *   The same DESTination system name as was used with the SOURce tag is used when the
  1856.           destination is unknown.
  1857.  
  1858. TEMPLE_VALUE:=                                            {Size=5:5}
  1859.     A 5-character abbreviation of the temple in which LDS temple ordinances are performed.
  1860.     (Contact the GEDCOM Coordinator for a table of valid abbreviations)
  1861.  
  1862. TEXT:=                                                    {Size=1:247}
  1863.     A string composed of any valid character or string of characters in the GEDCOM character set.
  1864. TIME_PERIOD:=         {Size=1:90}
  1865.     [ FROM <DATE_REGULAR> TO <DATE_REGULAR> |
  1866.       FROM <DATE_REGULAR> |
  1867.       TO <DATE_REGULAR> ]
  1868.     The range in time of an event or set of events, inclusive.  The choice FROM
  1869.     <DATE_REGULAR> indicates a range from a beginning date to an indefinite future date.
  1870.     This differs from the date range notation in that the date range is to indicate that an event took
  1871.     place on a given date within the range.  The time period date indicates that the event or events
  1872.     cover or happened over the time period specified.
  1873.  
  1874.     The choice TO <DATE_REGULAR> indicates from an indefinite beginning to a specified
  1875.     date.
  1876.     Examples:
  1877.        FROM 1904 to 1915
  1878.        FROM 1904    
  1879.        TO 1905
  1880.  
  1881. TIME_VALUE:=          {Size=1:10}
  1882.      [ hh:mm:ss.fs ]
  1883.     The time of a specific event, usually a computer-timed event, where:
  1884.     hh = hours on a 24 hour clock
  1885.     mm = minutes
  1886.     ss = seconds, (optional)
  1887.     fs = decimal fraction of a second, (optional)
  1888.  
  1889. TRANSMISSION_DATE:=                                       {Size=10:11}
  1890.     <DATE_EXACT>
  1891.     The date that this transmission was created.
  1892.  
  1893. TYPE_OF:=             {Size=1:20}
  1894.     A user-defined number or text that the submitter uses to identify this record.  For instance, it
  1895.     may be a record number within the submitter's automated or manual system, or it may be a page
  1896.     and position number on a pedigree chart.
  1897.  
  1898. USER_TAG_DEFINITION:=
  1899.     A formal description of the user defined tag.  This description can be used by the receiving
  1900.     system to give meaning to the user defined tags.  (See Chapter 2, User Defined Tags section.)
  1901.  
  1902. VERSION_NUMBER:=                                          {Size=1:15}
  1903.     An identifier that represents the version level assigned to the associated product.  It is defined
  1904.     and changed by the creators of the product.
  1905.  
  1906. XREF:=                                                    {Size=1:15}
  1907.     Either a pointer or a cross-reference identifier.  If this element appears before the tag in a
  1908.     GEDCOM-line, then it is a cross-reference identifier.  If it appears after the tag in a GEDCOM-
  1909.     line, then it is a pointer.  The method of delimiting a pointer or cross-reference identifier is to
  1910.     enclose the pointer or cross reference identifier within at-signs (@), for example, @I123@.  A
  1911.     XREF may not begin with a number sign (#).  This is to avoid confusion with an escape
  1912.     sequence prefix (@#). The use of a colon (:) in the XREF is reserved for creating future
  1913.     network cross-references.
  1914. XREF:ANY:=                                                {Size=1:15}       
  1915.    <XREF>                                                                     
  1916.    A universal pointer.  It may point to any other cross-reference identifier type.   
  1917.  
  1918. XREF:EVEN:=                                               {Size=1:15}       
  1919.    <XREF>                                                                     
  1920.    A pointer to or a cross reference identifier of a source event   
  1921.    record.                                                                    
  1922.                                                                               
  1923. XREF:FACT:=                                               {Size=1:15}       
  1924.    <XREF>                                                                     
  1925.    A pointer to or a cross reference identifier of a facts record.
  1926.                                                         
  1927. XREF:FAM:=                                                {Size=1:15}
  1928.     <XREF>
  1929.     A pointer to or a cross reference identifier of a family record.
  1930.  
  1931. XREF:INDI:=                                               {Size=1:15}
  1932.     <XREF>
  1933.     A pointer to or a cross reference identifier of an individual record.
  1934.  
  1935. XREF:NOTE:=                                               {Size=1:15}
  1936.     <XREF>
  1937.     A pointer to or a cross reference identifier of a note record.
  1938.  
  1939. XREF:REPO:=                                               {Size=1:15}
  1940.     <XREF>
  1941.     Either a pointer to a REPOsitory, a SUBMitter, or an INDIvidual record, or a cross reference
  1942.     identifier of a repository record.
  1943.  
  1944. XREF:REC!ID:=                                             {Size=1:15}
  1945.     [ <FILE:REC!ID> | <REC!ID> | <!ID> ] 
  1946.     Enclosed in at-signs (@), this is a pointer to a context within a record.  Normally the pointer
  1947.     will only be used to point to role contexts within the current event record but the principle
  1948.     should allow the reference to a context within a specific record within a specific file.  The
  1949.     following are valid ways of representing this pointer:
  1950.    
  1951.    @FILE:REC!ID@  =       A pointer to a specific context <!ID>, within a specific record
  1952.                           <REC> within a specific file <FILE:>, that logically replaces  the
  1953.                           context containing the cross reference pointer. (Future.)
  1954.  
  1955.     @REC!ID@      =       A pointer to a specific context <!ID> within a specific record within the
  1956.                           current GEDCOM transmission.
  1957.    not valid:
  1958.     @!ID@         =       A pointer to a specific context <!ID> within the current record of this
  1959.                           GEDCOM transmission must also contain the record level pointer, such
  1960.                           as @I13!3@.
  1961.  
  1962. XREF:SOUR:=                                               {Size=1:15}
  1963.     <XREF>
  1964.     Either a pointer to a SOURce, a SUBMitter, or an INDIvidual record, or a cross reference
  1965.     identifier of a source record.
  1966.  
  1967. XREF:SUBM:=                                               {Size=1:15}
  1968.     <XREF>
  1969.     Either a pointer to a SUBMitter, or an INDIvidual record, or a cross reference identifier of a
  1970.     submitter record.
  1971.  
  1972. YEAR:=                                                    {Size=3:4, Type=NUMBER}
  1973.     A numeric representation of the calendar year in which an event occurred.  
  1974.  
  1975. YEAR_ALTERNATIVE:=                                        {Size=1:1, Type=NUMBER}
  1976.     A year modifier which shows the possible date alternatives for pre-1752 date brought about by a
  1977.     calendar change, for example, 15 Dec 1752/3.
  1978.  
  1979. COMPATIBILITY WITH OTHER GEDCOM VERSIONS
  1980.  
  1981. Products based on GEDCOM 5.3 are generally compatible with products based on prior GEDCOM
  1982. versions.  However, there are four issues related to specific products that introduce incompatibilities
  1983. which can be accommodated by programming to handle the information in both the standard and the
  1984. non-standard way.  Compatibility with prior implementations may be maintained by doing the
  1985. following:
  1986.  
  1987. 1.    Treat a TITL tag found at level 0 as if it were a SOUR record, including its subordinate
  1988.       structure.  Roots III points from a SOUR structure in an INDI record to a 0 TITL source
  1989.       record in this manner.  Likewise, the TITL tag must be used instead of the SOUR tag in the
  1990.       level 0 SOUR record to send source information to Roots III.
  1991.  
  1992. 2.    The structure for LDS sealing of child to parents was changed in the standard from the FAM-
  1993.       CHIL-SLGC structure to the INDI-FAMC-SLGC structure to conform with the more natural
  1994.       access path to this information.  PAF 2.1 reads the sealing date in the FAM-CHIL-SLGC
  1995.       structure, while other products read it in the INDI-FAMC-SLGC structure.  To accommodate
  1996.       all implementations, systems handling the LDS ordinance events should look for the child
  1997.       sealing information in either place.  Systems should also write the child sealing information in
  1998.       both structures when preparing a transmission.  Other child events were also moved to the
  1999.       INDI-FAMC structure, namely ADOPtion, which should receive the same treatment.
  2000.  
  2001. 3.    When an individual has multiple names, GEDCOM 5.x requires listing the preferred instance
  2002.       first, followed by less-preferred names.  However, PAF and other products take only the last
  2003.       instance during a transmission, causing the preferred name to be dropped when more than one
  2004.       name is present.  The same happens with all multiple-instance tags where only one instance is
  2005.       received.  When writing to GEDCOM 4.0 (or earlier) compatible systems you should only
  2006.       output the preferred name under the name tag and export the also-known-as name in a note
  2007.       field.
  2008.  
  2009. We anticipate a future change to allow use of indentation to make GEDCOM files easier to read. 
  2010. To make this transition easier, beginning with GEDCOM 5.3, leading white space in a GEDCOM
  2011. line should be handled by receiving systems by ignoring it.  Indentation should NOT be transmitted
  2012. in GEDCOM files until this change is established in a future version of The GEDCOM Standard.
  2013.  
  2014. PACKAGING THE GEDCOM TRANSMISSION FILE
  2015.  
  2016. The GEDCOM transmission is normally created on a DOS or Macintosh compatible diskette.  The
  2017. DOS filename extension is (.GED).  Macintosh filenames do not use file extensions.
  2018.  
  2019. When the GEDCOM file is too large to fit on a single diskette, the file is divided after any whole-
  2020. line (last character is the terminator), and the DOS filename extension becomes (G##) where (##) is
  2021. (00) for the second disk, (01) for the third, and so forth.  For Macintosh filenames, append the two
  2022. digits to the subsequent filenames in parentheses. (See example below.)  This allows the receiving
  2023. software to ensure that disks are read in the correct sequence.
  2024.  
  2025. Given that the user-supplied portion of the file name is SMITH, then the complete filenames for a
  2026. three-disk transmission would be:
  2027.  
  2028. Disk      DOS Filename         Macintosh Filename
  2029.   1       SMITH.GED                  SMITH
  2030.   2       SMITH.G00                  SMITH(00)
  2031.   3       SMITH.G01                  SMITH(01)
  2032.  
  2033. The required GEDCOM HEADer record appears only on the first disk and the required TRLR
  2034. (trailer) record appears only on the last disk and must be followed by the  terminator.
  2035.  
  2036. USER DEFINED TAGS
  2037. Data stored in different systems within a user defined context will not be easy to share between
  2038. other systems.  GEDCOM defines a schema that can be included within the HEADer record which
  2039. will give receiving systems the information to assist them in interpreting the user defined data. 
  2040. Utmost care should be taken when defining User tags.  The primary use would be for transmitting
  2041. data between the same software driven system, system developers are encouraged to find ways of
  2042. supporting user defined tags, but GEDCOM only provides a way to express the data, it usage is left
  2043. to the receiving software.
  2044.  
  2045. This schema is designed to show:
  2046.       a.  The context within which the new tag appears in the records.
  2047.       b.  The name of the new tag, which must start with an underscore (_).
  2048.       c.  The definition of the new tag.
  2049.       d.  The label or long name of the new tag, if different from the tag name.
  2050.       e.  The kind of data that this new tag represents in terms of a predefined standard GEDCOM
  2051.           tag. For Example, if HOSPital was being defined as a user tag, then we would use the
  2052.           SITE tag to show that hospital is a kind of SITE.
  2053.  
  2054. In the Sample Lineage-linked GEDCOM Transmission example below is the SCHEMA required for
  2055. defining a new user defined tag "_HOSP" which is intended to show the name of the name of the
  2056. hospital where a birth took place.
  2057.  
  2058. Included in the schema context is:
  2059.       1.  The LABL tag to define a longer tag name that can be used as a field label.
  2060.       2.  The DEFN tag which allows sharing of the definition of the new tag.
  2061.       3.  The ISA tag to show that this tag is a kind of another standardized tag.  In this case
  2062.           _HOSPital is a kind of SITE.
  2063.  
  2064. ESCAPE SEQUENCE FORMAT FOR THE LINEAGE-LINKED FORM
  2065.  
  2066. The Lineage-linked form utilizes the escape sequence feature provided in the GEDCOM grammar in
  2067. the following way:
  2068.  
  2069.       *  An escape sequence in the HEADer structure invokes variant processing for the entire
  2070.          transmission.
  2071.  
  2072.       *  An escape sequence that appears in subsequent structures affect only the line on which the
  2073.          escape sequence appears unless that line has subordinate CONTinuation or CONCatenation
  2074.          lines.  In this case the variant processing applies to the subordinate CONTinuation and
  2075.          CONCatenation substructure lines as well.
  2076.  
  2077.       *  The form of the escape sequence is @# escape_type_code escape_text @ where the
  2078.          escape_type_code indicates that:
  2079.                  A =     A auxillary data format or processing is being referenced.  Auxillary data
  2080.                          formats include such forms as images, sound, or other data requiring
  2081.                          auxillary processing. (See primitive element
  2082.                          ESCAPE_TO_AUXILLARY_PROCESSING above in this chapter).  
  2083.  
  2084.                  C =     Character set processing is being invoked.
  2085.  
  2086.                  D =     Date processing for special calendar is being invoked. (see primitive
  2087.                          element CALENDAR_ESCAPE_SEQUENCE above in this chapter).
  2088.  
  2089.          The escape_text specifies the specific processing to be done within that particular type, for
  2090.          example, @#DJULIAN@ indicates julian date processing.
  2091.  
  2092. SAMPLE LINEAGE-LINKED GEDCOM TRANSMISSION
  2093.  
  2094. The example below shows how some of these value types appear in a valid GEDCOM Lineage-
  2095. linked transmission.   The example is a sample transmission of genealogical information about three
  2096. individuals who are members of the same family--husband, wife, and child.  In the example,
  2097. "Joe/Williams/" is the value specified by the tag NAME under the INDI tag for the record (@3@). 
  2098. Other values in other lines, such as the birth date and place, provide additional information about
  2099. Joe Williams. The value (@4@) specified by the FAMC tag is a pointer to the FAMily record
  2100. (@4@) of which Joe Williams is a child. Included also in this transmission example are three other
  2101. record types: a source record, a submitter record, and a repository record.  These records are
  2102. pointed to from within other records in the transmission.  This shows how pointer values can be
  2103. used in creating the GEDCOM Lineage-linked form.
  2104.  
  2105.       Example:  (Indentation is for readability only.)
  2106.        0 HEAD
  2107.          1 SOUR PAF
  2108.            2 VERS 2.1
  2109.          1 DEST ANSTFILE
  2110.          1 SUBM @5@
  2111.          1 GEDC
  2112.            2 VERS 5.2
  2113.          1 SCHEMA
  2114.            2 INDI
  2115.                3 BIRT
  2116.                  4 _HOSP
  2117.                    5 LABL HOSPITAL
  2118.                    5 DEFN The name of a hospital
  2119.                    5 ISA  SITE
  2120.        0 @1@ INDI
  2121.          1 NAME Robert Eugene/Williams/
  2122.          1 SEX M
  2123.          1 BIRT              
  2124.            2 DATE 02 OCT 1822
  2125.            2 PLAC Weston, Madison, Connecticut
  2126.            2 _HOSP St. Marks
  2127.            2 SOUR @6@
  2128.          1 DEAT              
  2129.            2 DATE 14 APR 1905
  2130.            2 PLAC Stamford, Fairfield, CT
  2131.            2 QUAY 2
  2132.          1 BURI              
  2133.            2 PLAC Stamford, CT
  2134.              3 CEME Spring Hill Cemetery 
  2135.          1 OCCU Publisher
  2136.          1 FAMS @4@
  2137.        0 @2@ INDI
  2138.          1 NAME Mary Ann/Wilson/
  2139.          1 SEX F
  2140.          1 BIRT
  2141.            2 DATE BEF 1828
  2142.            2 PLAC Connecticut
  2143.          1 FAMS @4@
  2144.        0 @3@ INDI
  2145.          1 NAME Joe/Williams/
  2146.          1 SEX M
  2147.          1 BIRT
  2148.            2 DATE 11 JUN 1861
  2149.            2 PLAC Idaho Falls, Bonneville, Idaho
  2150.          1 FAMC @4@
  2151.        0 @4@ FAM
  2152.          1 HUSB @1@
  2153.          1 WIFE @2@
  2154.          1 CHIL @3@
  2155.          1 MARR
  2156.            2 DATE DEC 1859
  2157.        0 @5@ SUBM
  2158.          1 NAME Reldon /Poulson/
  2159.          1 ADDR 1900 43rd Street West
  2160.            2 CONT Billings, MT 68051
  2161.            2 PHON (406) 555-1232
  2162.        0 @6@ SOUR
  2163.          1 TYPE VITAL
  2164.          1 EVEN BIRT
  2165.          1 TITL County Birth Records 
  2166.          1 PERI FROM 1820 TO 1825
  2167.          1 PLAC ,Madison, Connecticut
  2168.          1 RECO CIVIL
  2169.          1 FIDE PHOTOCOPY
  2170.          1 REPO @7@
  2171.            2 MEDI FILM
  2172.            2 CALN 13B-1234.01
  2173.        0 @7@ REPO
  2174.          1 NAME Family History Library
  2175.          1 ADDR 35 N West Temple Street
  2176.            2 CONT Salt Lake City, UT 84150
  2177.        0 TRLR
  2178.  
  2179.  
  2180. SAMPLE EVENT_RECORD
  2181.  
  2182. This example shows how the Evidence_Record format might be used to store an extraction of a
  2183. christening record:
  2184.  
  2185.          0 @EV13@ EVEN
  2186.           1 TYPE CHR
  2187.              2 DATE 17 NOV 1830
  2188.              2 PLAC Littlehampton, West Sussex, England
  2189.                 3 ADDR 9 Chiltern Close
  2190.                   4 CONT East Preston
  2191.              2 @EV13!1@ CHIL
  2192.                 3 NAME Jason \Wilde\
  2193.                 3 AGE 4 yrs
  2194.              2 @EV13!2@ MOTH
  2195.                 3 NAME Wilma \Wilson\
  2196.                 3 BIRT
  2197.                   4 DATE 15 MAY 1810
  2198.                   4 PLAC Nottingham, England
  2199.              2  @EV13!3@ FATH
  2200.                 3 NAME William \Wilde\
  2201.                 3 BIRT
  2202.                   4 DATE 15 OCT 1805
  2203.                   4 PLAC Nottingham, England
  2204.                 3 ASSO @EV13!4@
  2205.                   4 TYPE BROTHER
  2206.              2 @EV13!4@ GODF
  2207.                 3 NAME David \Wilde\          Chapter 3
  2208.                                     USING CHARACTER SETS IN GEDCOM
  2209.  
  2210. INTRODUCTION
  2211.  
  2212. GEDCOM needs to be designed to accommodate different character sets to facilitate the sharing of
  2213. genealogical data in different languages.  In order to minimize the number of differing standards to
  2214. accomplish this, we have chosen to have each system convert their usage to ANSEL and eventually
  2215. UNICODE.   In January of 1991 a Unicode Consortium was founded to promote the use of the
  2216. Unicode standard which accommodates all characters in one character set (see the section on
  2217. Unicode below).  Unicode Consortium has agreed with the ISO 10646 standard to merge and
  2218. Unicode will be a subset of the ISO 10646 international character encoding standard.  The difficulty
  2219. is in handling the two character code sequences.  Therefore, until the multi-byte handling becomes
  2220. more common, the usage of ANSEL to represent the latin-based international characters will be the
  2221. standard.
  2222.  
  2223. The GEDCOM specification does not address the implementation methods for multilingual
  2224. processing, such as keyboard arrangements, sorting sequences, or character and graphic
  2225. representations (font styles, proportional spacing, and so forth) on the CRT or printers, however,
  2226. Unicode standard has defined formatting characters which will indicate the direction of the text
  2227. presentation as well as other text formatting character codes.
  2228.  
  2229. Most of the genealogy systems developed so far utilize either ASCII or ANSEL, or both.  ANSEL
  2230. accommodates the set of Latin-based languages, as explained below.    
  2231.  
  2232. 8-Bit ANSEL
  2233.  
  2234. The 8-Bit ANSEL (American National Standard for Extended Latin Alphabet Coded Character Set
  2235. for Bibliographic Use, Z39.47, 1985 copyright) is the default character set for GEDCOM. It is used
  2236. for all transmissions of information unless another character set is specified.  The use of this
  2237. character set standard makes it possible to preserve the full integrity of the language by providing a
  2238. method of using the standard ASCII character set and supplementing it with both non-spacing
  2239. character modifiers (diacritic) as well as spacing special characters.  Non-spacing means that the
  2240. diacritic is printed without advancing the device's print position.  The character being modified is
  2241. then printed in the same position, resulting in a combined image of both the character and the
  2242. diacritic(s). The storage of ANSEL requires storing the non-spacing graphic character(s) preceding
  2243. the ASCII character that the diacritic is to modify.  The ANSEL standard specifies an extended 8-bit
  2244. configuration (above 128) to represent the spacing and non-spacing graphic characters that make up
  2245. most of the Latin based languages.  ANSEL is a super-set of ASCII.  The standard ASCII
  2246. characters including the control characters are preserved.
  2247.  
  2248. ANSEL is known by two other names: (1) ANSI Z39.47-1985) and (2) the American Library
  2249. Association character set, used in library systems worldwide, including the MARC (MAchine-
  2250. Readable Catalog) format.
  2251.  
  2252. A description of the codes for the ANSEL character set has been reproduced with permission and is
  2253. included with the printed version of The GEDCOM Standard. The description of ANSEL codes is
  2254. not included in the electronic version.  This description may be purchased from the American
  2255. National Standards Institute at 1430 Broadway, New York, N.Y. 10018. 
  2256. The description of the ANSEL character set standard includes the following:
  2257.        *       An 8-Bit Code Table showing the ASCII and extended ANSEL codes
  2258.        *       An explanation or legend of these codes
  2259.        *       A chart that identifies the ANSEL Non-spacing Graphic Characters
  2260.        *       A chart that identifies the ASCII Control Characters
  2261.        *       A chart that identifies the ASCII Graphic Characters
  2262.  
  2263. Character-set codes 0 through 127 are the same for 8-Bit ANSEL and 8-Bit ASCII (USA version--
  2264. ANSI 8-Bit). Character-set codes 128 through 255 are unique to the ANSEL character set.
  2265.  
  2266. ASCII (USA version)
  2267.  
  2268. When there isn't a need for diacritics or other special characters, and if you are not transmitting
  2269. binary data, you will find it convenient to use ASCII (8-bit USA version) if your computer already
  2270. supports it. This is a standard of the American National Standards Institute (ANSI). Most of the
  2271. basic printable characters of ANSEL and ASCII (USA version--ANSI 8-Bit) are identical.
  2272.  
  2273. Binary Character Set
  2274.  
  2275. Binary formats for representing photographs and other bit-mapped graphics should use the escape
  2276. sequence "escape_to_supplementary_processing" for linking supplementary files to the GEDCOM
  2277. context (see chapter 2).
  2278.  
  2279. UNICODE (ISO 10646)
  2280.  
  2281. The Unicode standard is a new character code designed to encode text for storage in computer files. 
  2282. It is a subset of the upcoming ISO 10646 standard.  The design of the Unicode standard is based on
  2283. the simplicity and consistency of today's prevalent character code set, extended ASCII code set, but
  2284. goes far beyond ASCII's limited ability to encode only the Latin alphabet: the Unicode encoding
  2285. provides the capacity to encode all of the characters used for written languages throughout the
  2286. world.  In order to accommodate the many thousands of characters used in the international text, the
  2287. Unicode standard uses a 16-bit code set instead of extended ASCII's 8-bit code set.  This expansion
  2288. provides codes for more than 65,000 characters.  The Unicode standard assigns each character a
  2289. unique 16-bit value, and does not use complex modes or escape codes to specify modified characters
  2290. or special cases. The text representation of the Unicode 16-bit numbers is U+0041 which is
  2291. assigned to the letter A, 65 decimal.  The Unicode standard includes the Latin alphabet used for
  2292. English, the Cyrillic alphabet used for Russian, the Greek, Hebrew, and Arabic alphabets.  Other
  2293. alphabets used in countries across Europe, Africa, the Indian subcontinent, and Asia, such as
  2294. Japanese Kana, Korean Hangul, and Chinese Bopomofo are included.  The largest part of the
  2295. Unicode standard is devoted to thousands of unified character codes for Chinese, Japanese, and
  2296. Korean ideographs.  (See "The Unicode standard", vol. 1 and 2, published by Addison-Wesley
  2297. Publishing, for character code standards.)
  2298.  
  2299. The Unicode character set environment, which contains a character set for all languages, minimizes
  2300. previous GEDCOM requirements to provide escape_sequences for moving from one character set to
  2301. another.  If the Unicode environment is used to produce a GEDCOM transmission, the header
  2302. record would also be in Unicode, requiring receiving systems to determine whether the transmission
  2303. is Unicode or ASCII before they could interpret the GEDCOM header.  This would be done by
  2304. reading the first two bytes of the transmission.  If the first two bytes are 0x30 and 0x20 then the
  2305. transmission will be in either ASCII or ANSEL as determined by the header record.  If the first two
  2306. bytes are 0x30 and 0x00 then the transmission should be processed as a Unicode transmission.
  2307. (Different platforms may reverse the position of the null byte, in which case the test would be for
  2308. 0x00 and 0x30.)
  2309.  
  2310. How to change character sets
  2311.  
  2312. The character set for an entire transmission is specified in the character-set line of the header
  2313. record. 
  2314.  
  2315.        The example below shows the specification in the header record.
  2316.  
  2317.        Example:
  2318.        Lvl     Tag    Value
  2319.        0       HEAD
  2320.        1       SOUR          PAF
  2321.        2       VERS          2.1
  2322.        1       DEST          ANSTFILE
  2323.        1       CHAR          ANSEL
  2324.  
  2325. The character-set change remains in effect until the TRLR record is encountered at the end of the
  2326. transmission.
  2327.  
  2328. The lineage_linked form no longer makes use of the character escape_sequence to change a
  2329. character set context inside of the transmission.  Unicode does not require shifting from character
  2330. set to character set and we should encourage its use for multi-language support.
  2331.  
  2332. For more information about character sets, see the following:
  2333.  
  2334. *      Extended Latin Alphabet Coded Character Set for Bibliographic Use. American National
  2335.        Standards (ANSI), Z39.47, 1985.
  2336.  
  2337. *      "8-Bit ASCII--Structure and Rules." American National Standards (ANSI) X3.134.1-198x.
  2338.  
  2339. *      "7-Bit and 8-Bit ASCII Supplemental Multilingual Graphic Character Set (ASCII Multilingual
  2340.        Set)" (manuscript). American National Standards (ANSI), X3.134.2-198x.
  2341.  
  2342. *      "The Unicode standard", vol. 1 and 2, published by Addison-Wesley Publishing.
  2343.  
  2344.                                              Appendix A
  2345.                                  LINEAGE-LINKED GEDCOM TAG DEFINITION
  2346.  
  2347. Introduction
  2348.  
  2349. Appendix A is a glossary of the tags approved for use with Lineage-linked GEDCOM. (See chapter
  2350. 2 for an example of the tags in context that describes the Lineage-linked structure.)  Every tag must
  2351. be used within the context shown to ensure that all information transmitted by means of GEDCOM
  2352. is uniformly identified.
  2353.  
  2354. The tags vary in type, depending on their role or use in a transmission. They are used to identify
  2355. individuals, families, names, dates, places, events, roles, sex, sources, relationships, control codes
  2356. and other kinds of data for computers, computer programs, and computer systems.
  2357.  
  2358. Generally, the definition for each tag is broad enough to cover all uses of the tag. Any new tag
  2359. needed to extend the Lineage-linked form can be used for by a system that generates GEDCOM
  2360. output may be used and will not violate the Lineage-linked GEDCOM standard as long as the
  2361. context for the Lineage-linked GEDCOM grammar is not violated.  System builders using new tags
  2362. should register them and their definitions with the GEDCOM Coordinator at the address listed on
  2363. the title page of this document.  The Coordinator will evaluate the feasibility of including them as a
  2364. part of the next release of the standard.  Suggestions and proposed additions are welcome. 
  2365.  
  2366.  
  2367. Lineage-Linked GEDCOM Tag Definitions
  2368.  
  2369. This section provides the definition of the standardized GEDCOM tags and shows the formal name
  2370. of the tag inside of {braces}.
  2371.  
  2372. ADDR {ADDRESS}:=
  2373.        The contemporary place, usually required for postal purposes, of an individual, a submitter
  2374.        of information, a repository, a business, a school, or a company.
  2375.  
  2376. ADOP {ADOPTION}:=
  2377.        The event of a legal creation of the child-parent relationship that does not exist biologically.
  2378.  
  2379. AFN {AFN}:=
  2380.        A unique permanent record file number of an individual record stored in the Ancestral File.   
  2381.        
  2382. AGE  {AGE}:=
  2383.        The age of the individual at the time an event occurred, or the age listed in the document.
  2384.  
  2385. AGNC {AGENCY}:=
  2386.        The name of the branch of government.
  2387.  
  2388. ALIA {ALIAS}:=
  2389.        A pointer to which indicates that another record is suspected of being the same person. 
  2390.        When the suspicions are confirmed, drop the alias line, combine all data into one record, and
  2391.        delete the other record.  Alias should NOT be used to record alternate names for the same
  2392.        person. (See Name tag definition.)
  2393. ANCI {ANCES_INTEREST}:=
  2394.        Indicates an individual in which the submitter has interest in additional research for ancestors
  2395.        of this individual. (See also DESI)
  2396.  
  2397. ANUL {ANNULMENT}:=
  2398.        An event declaring a marriage void from the beginning (never existed).
  2399.  
  2400. ARVL {ARRIVAL}:=
  2401.        An event declaring the arrival or reaching of a destination.
  2402.  
  2403. ASSO {ASSOCIATES}:=
  2404.        Identifies friends, neighbors, or associates of an individual.
  2405.  
  2406. AUTH {AUTHOR}:=
  2407.        The name of the individual who created or compiled information.
  2408.                                                                              
  2409. BAPL {BAPTISM-LDS}:=
  2410.        The event of baptism performed at age eight or later by priesthood authority of The Church
  2411.        of Jesus Christ of Latter-day Saints. (See also BAPM.)
  2412.  
  2413. BAPM {BAPTISM}:=
  2414.        The event of baptism (not LDS), performed in infancy or later. (See also BAPL and CHR.
  2415.  
  2416. BARM {BAR_MITZVAH}:=
  2417.        The ceremonial event held when a Jewish boy reaches age 13.
  2418.  
  2419. BASM {BAS_MITZVAH}:=
  2420.        The ceremonial event held when a Jewish girl reaches age 12, also known as "Bat Mitzvah".
  2421.  
  2422. BIRT {BIRTH}:=
  2423.        The event of entering into life.
  2424.  
  2425. BLES {BLESSING}:=
  2426.        A religious event of bestowing divine care or intercession.
  2427.  
  2428. BROT {BROTHER}:=
  2429.        A male sibling.
  2430.  
  2431. BURI {BURIAL}:=
  2432.        The event of the proper disposing of the mortal remains of a deceased person.
  2433.  
  2434. BUYR {BUYER}:=
  2435.        A person who purchased or purchases from another.
  2436.  
  2437. CALN {CALL_NUMBER}:=
  2438.        The number used by a repository to identify the specific items in its collections.
  2439.  
  2440. CAST {CASTE}:=                                                                
  2441.    The name of an individual's rank or status in society, based    
  2442.    on racial or religious differences, or differences in wealth, inherited    
  2443.    rank, profession, occupation, etc.
  2444.  
  2445. CAUS {CAUSE}:=
  2446.        A description of the cause of the associated event or fact, such as the cause of death.  
  2447.  
  2448. CEME {CEMETERY}:=
  2449.        The name of the cemetery or other resting place where an individual is buried.
  2450.  
  2451. CENS {CENSUS}:=
  2452.        The event of the periodic count of the population for a designated locality, such as a national
  2453.        or state Census.
  2454.  
  2455. CHAN {CHANGE}:=
  2456.        Indicates a change, correction, or modification. Typically used in connection with a DATE to
  2457.        specify when a change in information occurred.
  2458.  
  2459. CHAR {CHARACTER}:=
  2460.        An indicator of the character set used in writing this automated information.
  2461.  
  2462. CHIL {CHILD}:=
  2463.        The natural, adopted, or sealed (LDS) child of a father and a mother.
  2464.  
  2465. CHR  {CHRISTENING}:=
  2466.        The religious event (not LDS) of baptizing and/or naming a child. 
  2467.  
  2468. CHRA {ADULT_CHRISTNG}:=
  2469.        The religious event (not LDS) of baptizing and/or naming an adult person.
  2470.  
  2471. CLAS {CLASSIFICATION}:=
  2472.        A classification name given to identify objects because they posses a set of similar attributes
  2473.        or characteristics.
  2474.  
  2475. CNTC {CONTACT_PERSON}:=
  2476.        The name of a person that is listed as the contact person at an institution such as a
  2477.        repository, college, business, etc.
  2478.  
  2479. CONC {CONCATENATION}:=
  2480.        An indicator that the additional value information follows and is to be connected to the value
  2481.        of the superior preceding line without a new line.
  2482.  
  2483. CONF {CONFIRMATION}:=
  2484.        The religious event (not LDS) of conferring the gift of the Holy Ghost and, among
  2485.        protestants, full church membership.
  2486.  
  2487. CONL {CONFIRMATION_L}:=
  2488.        The religious event by which a person receives membership in The Church of Jesus Christ of
  2489.        Latter-day Saints.
  2490.  
  2491. CONT {CONTINUED}:=
  2492.        An indicator that additional value information follows and is to be connected with the value
  2493.        of the superior preceding line as a new line.
  2494.  
  2495. COPR {COPYRIGHT}:=
  2496.        A statement that accompanies data to protect it from unlawful duplication and distribution.
  2497.  
  2498. CORP {CORPORATE}:=
  2499.        A name of an institution, agency, corporation, or company.
  2500.  
  2501. CPLR {COMPILER}:=
  2502.        The name of the person that compiled writings of others.
  2503.  
  2504. DATA {DATA}:=
  2505.        Pertaining to stored automated information.
  2506.  
  2507. DATE {DATE}:=
  2508.        The time of an event in calendar days.
  2509.  
  2510. DEAT {DEATH}:=
  2511.        The event when mortal life terminates.
  2512.  
  2513. DEFN {DEFINITION}:=
  2514.        A textual description of something.
  2515.  
  2516. DESI {DESCENDANT_INT}:=
  2517.        Indicates the submitter that has interest in research to identify additional descendants of this
  2518.        individual. (See also ANCI.)
  2519.  
  2520. DEST {DESTINATION}:=
  2521.        A system receiving data.
  2522.  
  2523. DIV  {DIVORCE}:=
  2524.        An event of dissolving a marriage through civil action.
  2525.  
  2526. DIVF {DIVORCE_FILED}:=
  2527.        An event of filing for a divorce by a spouse.
  2528.  
  2529. DPRT {DEPARTURE}:=
  2530.        An event declaring the departure or leaving for another destination.
  2531.  
  2532. DSCR {PHY_DESCRIPTION}:=
  2533.        The physical characteristics of a person, place, or thing.
  2534.  
  2535. EDTR {EDITOR}:=
  2536.        The name of a person who edited information.
  2537.  
  2538. EDUC {EDUCATION}:=
  2539.        Indicates the education attained.
  2540.  
  2541. ENDL {ENDOWMENT}:=
  2542.        A religious event where an endowment ordinance for an individual was performed by
  2543.        priesthood authority in an LDS Temple.
  2544.  
  2545. ENGA {ENGAGEMENT}:=
  2546.        An event of recording or announcing an agreement between two people to become married.
  2547.  
  2548. EMIG {EMIGRATION}:=
  2549.        An event of leaving one's homeland with the intent of residing elsewhere.
  2550.  
  2551. EVEN {EVENT}:=
  2552.        A noteworthy event related to an individual, a group, or an organization.
  2553.  
  2554. FAM {FAMILY}:=
  2555.        Identifies a legal, common law, or other customary relationship of husband and wife and
  2556.        their children, if any, or a family created by virtue of the birth of a child to its biological
  2557.        father and mother.
  2558.  
  2559. FAMC {FAMILY_CHILD}:=
  2560.        Identifies the family in which an individual appears as a child.
  2561.  
  2562. FAMS {FAMILY_SPOUSE}:=
  2563.        Identifies the family in which an individual appears as a spouse.
  2564.  
  2565. FATH {FATHER}:=
  2566.        Identifies the male parent in a family.  In the Lineage-linked form this tag is used only in the
  2567.        EVENT_RECORD role tag structure (See Chapter 2).  Direct parent relationships are
  2568.        represented using the HUSBand and WIFE tags as part of the FAMILY_RECORD.
  2569.  
  2570. FIDE {FIDELITY}:=
  2571.        A description of the state of originality of the record to permit an assessment of the potential
  2572.        for accuracy or errors due to the use of a copy of the record.
  2573.  
  2574. FILE {FILE}:=
  2575.        An information storage place that is ordered and arranged for preservation and reference.
  2576.  
  2577. FILM {FILM_NUMBER}:=
  2578.        An assigned, unique number used to identify a reel of film.
  2579.  
  2580. FORM {FORMAT}:=
  2581.        An assigned name given to a consistent format in which information can be conveyed.  
  2582.  
  2583. GEDC {GEDCOM}:=
  2584.        Information about the use of GEDCOM in a transmission.
  2585.  
  2586. GODP {GODPARENT}:=
  2587.        A sponsor at a religious rite (baptism).
  2588.  
  2589. GRAD {GRADUATION}:=
  2590.        An event of awarding educational diplomas or degrees to individuals.
  2591.  
  2592. HDOH {HEAD_HOUSEHOLD}:=
  2593.        Identifies a person whose role was recorded as "head of household" for an event such as a
  2594.        census.
  2595.  
  2596. HEAD {HEADER}:=
  2597.        Identifies information pertaining to an entire GEDCOM transmission.
  2598.  
  2599. HEIR {HEIR}:=
  2600.        A role of an individual who inherited or is entitled to inherit an estate.
  2601.  
  2602. HFAT {HUSB_FATHER}:=
  2603.        A role of an individual acting as the husband's father for a cited event.
  2604.                
  2605. HMOT {HUSB_MOTHER}:=
  2606.        A role of an individual acting as the husband's mother for a cited event.
  2607.  
  2608. HUSB {HUSBAND}:=
  2609.        An individual in the family role of a married man or father.
  2610.  
  2611. IDNO {IDENT_NUMBER}:=
  2612.        A number assigned to identify a person within some significant external system.
  2613.  
  2614. IMMI {IMMIGRATION}:=
  2615.        An event of entering into a new locality with the intent of residing there.
  2616.  
  2617. INDI {INDIVIDUAL}:=
  2618.        A person.
  2619.  
  2620. INDX {INDEXED}:=
  2621.        Specifies information about an index to simplify finding information in a source.
  2622.  
  2623. INFT {INFORMANT}:=
  2624.        An individual who reported facts concerning an event.
  2625.  
  2626. INTV {INTERVIEWER}:=
  2627.        The person who facilitated, recorded, and obtained information during an interview.
  2628.  
  2629. ISA  {IS_A_KIND_OF}:=
  2630.        Indicates the tag of an object of which this object inherits its characteristics from.
  2631.  
  2632. ISSUE  {ISSUE}:=
  2633.        An identifier used to differentiate one giving out from another, such as a number
  2634.        differentiating one periodical publication from another. 
  2635.  
  2636. ITEM {ITEM}:=
  2637.        Refers to a unit within a set of things that belong together.  The unit itself may be made up
  2638.        of other objects but collectively they are referred to as an unit (item) of the set.  A group of
  2639.        papers filmed together under one header page is referred to as an item on a film.
  2640.  
  2641. LABL {LABEL}:=
  2642.        A name assigned to a field or product which helps to identify it.
  2643.        
  2644. LANG {LANGUAGE}:=
  2645.        The name of the language used in a communication or transmission of information.
  2646.  
  2647. LCCN {LIB_CONGRS_CALL}:=
  2648.        The number assigned by the U.S. Library of Congress to a document, book, etc.
  2649.  
  2650. LGTE {LEGATEE}:=
  2651.        A role of an individual acting as a person receiving a bequest or legal devise.
  2652.  
  2653. MARB {MARRIAGE_BANN}:=
  2654.        An event of an official public notice given that two people intend to marry.
  2655.  
  2656. MARC {MARR_CONTRACT}:=
  2657.        An event of recording a formal agreement of marriage, including the prenuptial agreement in
  2658.        which marriage partners reach agreement about the property rights of one or both, securing
  2659.        property to their children.
  2660.  
  2661. MARL {MARR_LICENSE}:=
  2662.        An event of obtaining a legal license to marry.
  2663.  
  2664. MARR {MARRIAGE}:=
  2665.        A legal, common-law, or customary event of creating a family unit of a man and a woman as
  2666.        husband and wife.
  2667.  
  2668. MARS {MARR_SETTLEMENT}:=
  2669.        An event of creating an agreement between two people contemplating marriage, at which
  2670.        time they agree to release or modify property rights that would otherwise arise from the
  2671.        marriage.
  2672.  
  2673. MEDI {MEDIA}:=
  2674.        The medium used to store or transmit information.
  2675.  
  2676. MBR {MEMBER}:=
  2677.         Identifies an individual (element)  belonging to a group (set).
  2678.  
  2679. MOTH {MOTHER}:=
  2680.        Identifies the female parent in a family.  In the Lineage-linked form this tag is used only in
  2681.        the EVENT_RECORD role tag structure (See Chapter 2).  Parent relationships are
  2682.        represented using the HUSBand and WIFE tags as part of the FAMILY_RECORD.
  2683.  
  2684. NAME {NAME}:=
  2685.        A word or combination of words used to help identify an individual, title, or other item.
  2686.        More than one NAME line should be used for people who were known by multiple names.
  2687.  
  2688. NAMR {NAME_RELIGIOUS }:=
  2689.        A name given to an individual to be used in association with one's religion.
  2690.  
  2691. NAMS {NAME_SAKE}:=
  2692.        Identifies the person that an individual is named after to perpetuate the person's name.
  2693.  
  2694. NATI {NATIONALITY}:=
  2695.        The national heritage of an individual.
  2696.  
  2697. NATU {NATURALIZATION}:=
  2698.        The event of obtaining citizenship.
  2699.  
  2700. NCHI {CHILDREN_COUNT}:=
  2701.        The number of children that this person is known to be the parent of (all marriages), or that
  2702.        belong to this family.
  2703.  
  2704. NMR {MARRIAGE_COUNT}:=
  2705.        The number of times this person has participated in a family as a spouse or parent.
  2706.  
  2707. NOTE {NOTE}:=
  2708.        Additional information provided by the submitter for understanding the enclosing data.
  2709.  
  2710. OCCU {OCCUPATION}:=
  2711.        The type of work or profession of an individual.
  2712.  
  2713. OFFI {OFFICIATOR}:=
  2714.        A person acting in an authorized capacity as voice in performing an ordinance or ceremony.
  2715.  
  2716. ORDN {ORDINATION}:=
  2717.        A religious event of receiving authority to act in religious matters.
  2718.  
  2719. ORIG {ORIGINATION}:=
  2720.        Pertains to the creation or root of an object.
  2721.  
  2722. OWNR {OWNER}:=
  2723.        The name of the person who is the owner of the associated item or property.
  2724.  
  2725. PAGE {PAGE}:=
  2726.        A number or description to identify the page in a document.
  2727.  
  2728. PERI {PERIOD}:=
  2729.        Indicates the range of time during which an event took place.
  2730.  
  2731. PHON {PHONE}:=
  2732.        A unique number assigned to dial a specific telephone.
  2733.  
  2734. PHOTO {PHOTO}:=
  2735.        A photograph (graphic image) of a person, place, or thing, depending on the enclosing
  2736.        context.
  2737.  
  2738. PHUS {PREV_HUSB}:=
  2739.        An individual in the role of the principal's previous husband for a cited event.
  2740.  
  2741. PLAC {PLACE}:=
  2742.        A jurisdictional name to identify the place or location of an event.
  2743. PORT {PORT}:=
  2744.        A site identifier of entering or leaving, such as an air port, harbor, port of entry, or a data
  2745.        port where data enters or leaves a system.
  2746.  
  2747. PROB {PROBATE}:=
  2748.        An event of judicial determination of the validity of a will.  May indicate several related
  2749.        court activities over several dates.
  2750.  
  2751. PROP {PROPERTY}:=
  2752.        The name of land and/or other properties possessed by this individual. 
  2753.  
  2754. PUBL {PUBLICATION}:=
  2755.        A published work.
  2756.  
  2757. PUBR {PUBLISHER}:=
  2758.        The name of the company or individual who published a work.
  2759.  
  2760. PWIF {PREV_WIFE}:=
  2761.        An individual in the role of the principal's previous wife for a cited event.
  2762.  
  2763. QUAY {QUALITY_OF_DATA}:=
  2764.        An assessment of the reliability of the evidence to support the conclusion drawn from the
  2765.        evidence.
  2766.  
  2767. RECO {RECORDER}:=
  2768.        A person responsible for recording information about an event, place, or person.
  2769.  
  2770. REFN {REFERENCE}:=
  2771.        A description or number used to identify an item for filing, storage, or other reference
  2772.        purposes.
  2773.  
  2774. REFS {REFERENCED_SOUR}:=
  2775.        A source that was referenced by the cited source but was not examined by the submitter. 
  2776.        Examined sources are listed using a SOUR tag.
  2777.  
  2778. RELI {RELIGION}:=
  2779.        A religious denomination to which a person is affiliated or for which a record applies.
  2780.  
  2781. REPO {REPOSITORY}:=
  2782.        An institution that has the specified item as part of its collection(s).
  2783.  
  2784. RETI {RETIREMENT}:=
  2785.        An event of exiting an occupational relationship with an employer after a qualifying time
  2786.        period.
  2787.  
  2788. RFN  {REC_FILE_NUMBER}:=
  2789.        A permanent number assigned to a record that uniquely identifies it within a known file.
  2790.  
  2791. ROLE {ROLE}:=
  2792.        A name given to a role played by an individual in connection with an event.
  2793. SCHEMA {SCHEMA}:=
  2794.        A context pattern definition that specifies the meaning and the valid context(s) of a user
  2795.        defined tag.  See the SCHEMA_STRUCTURE substructure definition.
  2796.  
  2797. SELR {SELLER}:=
  2798.        A person who sold or sells to another.
  2799.  
  2800. SEQU {SEQUENCE}:=
  2801.        Indicates the sequence or order of an event or information.
  2802.  
  2803. SERS {SERIES}:=
  2804.        Designates the volume within a series in which a given work is a part.
  2805.  
  2806. SEX {SEX}:=
  2807.        Indicates the sex of an individual--male or female.  No SEX line is present if the sex is
  2808.        unknown.
  2809.  
  2810. SIBL {SIBLING}:=
  2811.        A male or female child of a common parent.
  2812.  
  2813. SIGN {SIGNATURE}:=
  2814.        Used to identify information about an individual's signature.
  2815.  
  2816. SIST {SISTER}:=
  2817.        A female sibling.
  2818.  
  2819. SITE {SITE}:=
  2820.        The name of the specific location, building, etc. that is in connection with the address or
  2821.        place value, such as, "Shriners Hospital" or "The Church of the Epiphany".
  2822.  
  2823. SLGC {SEALING_CHILD}:=
  2824.        A religious event pertaining to the sealing of a child to his or her parents in an LDS temple
  2825.        ceremony.
  2826.  
  2827. SLGS {SEALING_SPOUSE}:=
  2828.        A religious event pertaining to the sealing of a husband and wife in an LDS temple
  2829.        ceremony.
  2830.  
  2831. SOUND {SOUND}:=
  2832.        A collection of sound bits pertaining to the enclosed context.
  2833.  
  2834. SOUR {SOURCE}:=
  2835.        The initial or original material from which information was obtained.
  2836.  
  2837. SPOU {SPOUSE}:=
  2838.        A husband or wife of a person.
  2839.  
  2840. SSN  {SOC_SEC_NUMBER}:=
  2841.        A number assigned by the United States Social Security Administration.  Used for tax
  2842.        identification purposes.
  2843. STAT {STATUS}:=
  2844.        An assessment of the state or condition of something.
  2845.  
  2846. SUBM {SUBMITTER}:=
  2847.        An individual or organization who contributes genealogical data to a file or transfers it to
  2848.        someone else.
  2849.  
  2850. TEMP {TEMPLE}:=
  2851.        The name or code that represents the name of a temple of The Church of Jesus Christ of
  2852.        Latter-day Saints.
  2853.  
  2854. TEXT {TEXT}:=
  2855.        The exact wording found in an original source document.
  2856.  
  2857. TIME {TIME}:=   
  2858.        A time value in a 24-hour clock format, including hours, minutes, and optional seconds,
  2859.        separated by a colon ":".  Fractions of seconds are shown in decimal notation.
  2860.  
  2861. TITL {TITLE}:=
  2862.        A descriptive description of a specific writing, such as the title of a book when used in a
  2863.        source context, or a formal designation used by an individual in connection with individual's
  2864.        name, such as Captain.
  2865.  
  2866. TRLR {TRAILER}:=
  2867.        At level 0, specifies the end of a GEDCOM transmission.
  2868.  
  2869. TXPY {TAXPAYER}:=
  2870.        A role of a person who has been assessed a tax.
  2871.  
  2872. TYPE {TYPE}:=
  2873.        A further qualification to the meaning of the associated superior tag.  The value does not
  2874.        have any computer processing reliability.  It is more in the form of a short one or two word
  2875.        note that should be displayed any time the associated data is displayed.
  2876.  
  2877. VERS {VERSION}:=
  2878.        Indicates which version of a product, item, or publication is being used or referenced.
  2879.  
  2880. WFAT {WIFE_FATHER}:=
  2881.        A role of an individual acting as the wife's father for a cited event.
  2882.  
  2883. WIFE {WIFE}:=
  2884.       An individual in the family role of a married woman or mother.
  2885.  
  2886. WILL {WILL}:=
  2887.        A legal document treated as an event, by which a person disposes of his or her estate, to take
  2888.        effect after death.  The event date is the date the will was signed while the person was alive.
  2889.        (See also PROBate.)
  2890.  
  2891. WITN {WITNESS}:=
  2892.        An individual who attested that he or she saw an event take place.
  2893. WMOT {WIFE_MOTHER}:=
  2894.        A role of an individual acting as the wife's mother for a cited event.
  2895.  
  2896. XLTR {TRANSLATOR}:=
  2897.        The name of a person who translated words from one language to another.
  2898.  
  2899.  
  2900.  
  2901.  
  2902.                                           THE GEDCOM STANDARD
  2903.  
  2904.  
  2905.  
  2906.  
  2907.  
  2908.  
  2909.  
  2910.  
  2911.  
  2912.  
  2913.  
  2914.  
  2915.  
  2916.                                               Appendix B
  2917.  
  2918.  
  2919.  
  2920.                                 PROPOSED EVENT AND ROLE TAG DEFINITIONS
  2921.  
  2922.  
  2923.  
  2924.  
  2925.  
  2926.  
  2927.  
  2928.  
  2929.  
  2930.  
  2931.  
  2932.  
  2933.  
  2934.  
  2935. The additional event and roll tags below have not yet been standardized.  They are shown here in
  2936. this draft form to obtain opinions as well as definitions.  We will standardize as many as makes
  2937. sense by the time the draft is finalized.  The underscore '_' in front of the tags indicate the tags
  2938. which have not been standardized and should be structured as user defined tags complete with your
  2939. own definition and classification using the ISA tag.  The other tags, the ones with the asterisk '*'
  2940. have been standardized and defined in the 5.x Appendix A.  Tags not appearing in Appendix A are
  2941. not used in any of the lineage-linked structures of 5.x and were therefore dropped from the standard
  2942. approved list.
  2943.  
  2944. Events:
  2945.  
  2946. TAG:                TAG NAME                     DEFINITION                         
  2947.  
  2948. _ABJUR              Abjuration
  2949. _ABSOL              Absolution
  2950. ADOP                Adoption*
  2951. _APPRN              Apprenticeship
  2952.  
  2953. BAPM                Baptism*
  2954. BIRT                Birth*
  2955.  
  2956. CENS                Census*
  2957. _CHARTR             Charter
  2958. CHR                 Christening*
  2959. _CITZN              Citizenship
  2960. _CIVIL              Court Civil
  2961. _CNFSCTN            Confiscation
  2962. _COMUN              Communion
  2963. CONF                Confirmation*           
  2964. _CRIME              Court Criminal
  2965. _CRTULRY            Cartulary
  2966.  
  2967. DEAT                Death*
  2968. _DEAT_NOTE          Death_Notice
  2969. DIV                 Divorce*
  2970. _DIV_ANUL           Divorce_Annulment
  2971. _DIV_SEP            Divorce_Separation
  2972. _DOWRY              Dowry
  2973. _DPORTN             Deportation
  2974.  
  2975. EDUC                Education*
  2976. EMIG                Emigration*
  2977. _EMPLYMT            Employment
  2978. _ENRLMNT            Enrollment - matriculation
  2979. _EXCUTN             Execution
  2980.  
  2981. _F_COMM             First_Communion
  2982. _FUNRL_HOME         Funeral Home
  2983. Events: (cont')
  2984.  
  2985. TAG:                TAG NAME                     DEFINITION                         
  2986.  
  2987. _GALLEY             Galley
  2988. GRAD                Graduation*
  2989.  
  2990. IMMI                Immigration*            
  2991. _INTRO              Introduction
  2992.  
  2993. _LAND               Land
  2994. _LND_LEAS           Land_Lease
  2995. _LND_PURC           Land_Purchase
  2996.  
  2997. _MARR_BTRO          Marriage_Betrothal
  2998. _MARR_CMLAW         Marriage Common Law
  2999. _MARR_CNSNU         Marriage_Consanguinity - marriage to blood relatives
  3000. _MARR_CNTRC         Marriage_Contract
  3001. _MARR_DIMIS         Marriage_Dimissorial    - permission to get married in another jurisdiction
  3002. _MARR_DISPN         Marriage_Dispensations
  3003. _MARR_ENGA          Marriage_Engagements
  3004. _MARR_INTNT         Marriage_Intention
  3005. _MARR_REHAB         Marriage_Rehabilitation
  3006. _MARR_BANN          Marriage_Banns - Announcements        
  3007. MARR                Marriage*
  3008.  
  3009. MILI                Military*
  3010. _MILI-INDU          Military_Induction
  3011. _MILI_DIS           Military_Discharge
  3012. _MISS_PRSN          Missing Person
  3013.  
  3014. _NAME_CHNG          Name Change     
  3015. NATU                Naturalization*
  3016.  
  3017. ORDN                Ordination*
  3018.  
  3019. _PASL               Passenger_List
  3020. _PASP               Passport
  3021. _POLI_RPT           Police_Reports
  3022. _POPL_REG           Population_Register
  3023. _POOR_LAW           Poor_law
  3024. PROB                Probate*
  3025.  
  3026. _ROSTR              Roster
  3027.  
  3028. _S_COMM             Solemn_Communion
  3029. _SASINE             Sasine
  3030. _SEPRTN             Separation
  3031. _SLAVE              Slavery
  3032. Events: (cont')
  3033.  
  3034. TAG:                TAG NAME                     DEFINITION                         
  3035.  
  3036. TXPY                Tax_payer*
  3037. _TSTMNT             Testament
  3038.  
  3039. _VOTE_REG           Voting_Registration
  3040. _VOW                Vow
  3041.  
  3042. WILL                Will*
  3043.  
  3044. Roles:
  3045. The following are roles which could be used to describe participants in events.  The status of these
  3046. tags are the same as those listed for the event tags listed above.
  3047.  
  3048. TAG:         TAG NAME                     DEFINITION                         
  3049.  
  3050. _ANCE               Ancestor
  3051. _APLCNT             Applicant       
  3052. _APPRN              Apprentice      
  3053. _APRSR              Appraiser       
  3054. _AUNT               Aunt     
  3055.  
  3056. _BISHP              Bishop   
  3057. _BOARDR             Boarder  
  3058. _BOROWR             Borrower        
  3059. _BRID               Bride    
  3060. _BRO                Brother  
  3061. BUYR                Buyer*
  3062.  
  3063. _CAPT               Captain
  3064. CHIL                Child*
  3065. _CLRGY              Clergymen       
  3066. _CMDR               Commander       
  3067. _COUSN              Cousins  
  3068. _CREW               Crew
  3069.  
  3070. _DEAD               Deceased        
  3071. _DESC               Descendant      
  3072.  
  3073. _EMPLYR             Employer
  3074. _EXCUTR             Executor
  3075. FATH                Father*
  3076. _FIANCE             Fiance
  3077. _FREND              Friend
  3078. TAG:         TAG NAME                     DEFINITION
  3079.  
  3080. _GODF               Godfather       
  3081. _GODM               Godmother       
  3082. GODP                Godparent*      
  3083. _GR_AUNT            Grand_Aunt      
  3084. _GR_FATH            Grand_Father    
  3085. _GR_MOTH            Grand Mother
  3086. _GR_UNCL            Grand_Uncle     
  3087. _GROO               Groom
  3088. _GUARDN             Guardian        
  3089.  
  3090. HDOH                Head_of_house*
  3091. _HEIR               Heir
  3092. HUSB                Husband*
  3093.  
  3094. INFT                Informant*      
  3095. _INSTR              Instructor      
  3096.  
  3097. _JRNYMN             Journeyman      
  3098. _JUDGE              Judge
  3099. _LENDR              Lender
  3100. _M_WIFE             Midwife
  3101. _MNSTR              Minister 
  3102. _MONK                        Monk   
  3103. MOTH                         Mother*
  3104. _MSTR                        Master
  3105.  
  3106. _NIECE              Niece
  3107. _NEPH                        Nephew         
  3108. _NLAW                        In_law         
  3109. _NLAW_BRO           Brother_in_law  
  3110. _NLAW_DAU           Daughter_in_law         
  3111. _NLAW_FATH          Father_in_law
  3112. _NLAW_MOTH          Mother_in_law   
  3113. _NLAW_SIS           Sister_in_law   
  3114. _NLAW_SON           Son_in_law
  3115. _NOTRY              Notary   
  3116. _NUN                Nun
  3117. _NURS               Nurse    
  3118.  
  3119. OFFI                Official*
  3120. _ORPHN              Orphan   
  3121.  
  3122. _PHYSN              Physician       
  3123. _PROF               Professor
  3124. _PRISNR             Prisoner 
  3125. _PATIENT            Patient  
  3126. _PASNGR             Passenger       
  3127. TAG:         TAG NAME                     DEFINITION
  3128.  
  3129. RECO                Recorder*
  3130. REL                 Relative*
  3131. _RNTR               Renter
  3132. _RSDNT              Resident        
  3133.  
  3134. _SASSIER            Sassier  
  3135. _SBLNG              Sibling
  3136. SELR                Seller*  
  3137. _SIS                Sister
  3138. _SLAV               Slave
  3139. _SOLDR              Soldier  
  3140. SPOU                Spouse*  
  3141. _SERVNT             Servant  
  3142. _STEWRT             Stewart
  3143. _STUD               Student  
  3144.  
  3145. _TEACHR             Teacher  
  3146. _TENANT             Tenant   
  3147.  
  3148. _UNCL               Uncle    
  3149.  
  3150. _WARD               Ward     
  3151. WIFE                Wife*
  3152. WITN                Witness*        
  3153.  
  3154.  
  3155.  
  3156.  
  3157.  
  3158.  
  3159.  
  3160.                                           THE GEDCOM STANDARD
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.  
  3173.  
  3174.                                               Appendix C
  3175.  
  3176.  
  3177.  
  3178.                                           ANSEL CHARACTER SET
  3179.  
  3180.  
  3181.  
  3182.  
  3183.  
  3184.  
  3185.  
  3186.  
  3187.  
  3188.  
  3189.  
  3190.  
  3191.  
  3192.  
  3193.                                      Reproduced by permission from
  3194.                                  American National Standards Institute
  3195.                                   1430 Broadway, New York, N.Y. 10018
  3196. The following tables show the spacing and non-spacing diacritic characters that are contained in the
  3197. ANSEL set.  This table was added to give help to those receiving the machine version to the
  3198. GEDCOM standard.  The graphic characters shown are not always accurate, however the name of
  3199. the diacritic and the decimal equivalent should agree with the ANSEL standard. 
  3200.  
  3201.           C/R column refers to the column and row of the American National Standard  Z39.47-
  3202.           1985 showing the ANSEL character graphic and its 8 bit binary representation.
  3203.  
  3204.           wpcode column shows the Wordperfect (code page , character number) (1,2) chosen as the
  3205.           closest representation of the diacritic as shown in Wordperfect Appendix P. of version
  3206.           (5.1) 
  3207.  
  3208.           Dec column shows to the decimal equivalent for that diacritic as is used in the ANSEL
  3209.           character set.
  3210.  
  3211.           Name column gives the english name of the diacritic.
  3212.  
  3213.           example of use column shows an example of words using this diacritic.  For the non-
  3214.           spacing diacritic, this mark appears before the character in which it should be
  3215.           superimposed.
  3216.  
  3217. ANSEL Non-spacing graphic characters
  3218. 8-bit
  3219. C/R   wpcode    Dec  Graphic    Name              example of use
  3220.  
  3221. 14/0      2,4      224    ■    low rising tone mark                  c■ui
  3222.  
  3223. 14/1      1,0      225    ■    grave accent                          r■egle
  3224.  
  3225. 14/2      1,6      226    ■    acute accent                          est■a
  3226.  
  3227. 14/3      1,3      227    ■    circumflex accent                     m■eme
  3228.  
  3229. 14/4      1,2      228    ■    tilde                                 ni■no
  3230.  
  3231. 14/5      1,8      229    ■    macron                                g■aj■ejs
  3232.  
  3233. 14/6      1,22     230    ■    breve                                 alt■a
  3234.  
  3235. 14/7      1,15     231    ■    dot above                             ■zaba
  3236.  
  3237. 14/8      1,7      232    ■    umlaut (diaeresis)                    ■oppna
  3238.  
  3239. 14/9      1,19     233    ■    hacek                                 v■zdy
  3240.  
  3241. 14/10     1,14     234    °    circle above (angstrm)                h°arANSEL Non-spacing graphic characters
  3242. 8-bit
  3243. C/R   wpcode    Dec  Graphic    Name              example of use
  3244.  
  3245. 14/11     2,11     235    ■    ligature, left half                   akademii■■a
  3246.  
  3247. 14/12     2,12     236    ■    ligature, right hlf                   akademii■■a
  3248.  
  3249. 14/13     1,10     237    ■    high comma, off center                rozde■lovac
  3250.  
  3251. 14/14     1,16     238    ■    double acute accent                   id■oszaki
  3252.  
  3253. 14/15     2,25     239    ■    candrabindu                           Ali■iev
  3254.  
  3255. 15/0      2,15     240    ■    cedilla                               ■ca
  3256.  
  3257. 15/1      2,17     241    ■    right hook                            viet■a
  3258.  
  3259. 15/2      2,0      242    ■    dot below                             te■da
  3260.  
  3261. 15/3      2,1      243    ■    double dot below                      khu■tbah
  3262.  
  3263. 15/4      2,3      244    ■    circle below                          Mahar■sicaritam■rtam
  3264.  
  3265. 15/5      2,6      245    ■    double underscore                     ■Ghulam
  3266.  
  3267. 15/6      2,7      246    ■    underscore                            samar
  3268.  
  3269. 15/7      2,16     247    ■    left hook                             darzi■na
  3270.  
  3271. 15/8      2,14     248    ■    right cedilla                         kh■ong
  3272.  
  3273. 15/9      2,9      249    ■    half circle below                     ■humantu■s
  3274.  
  3275. 15/10              250         double tilde, left half               ■ngalan
  3276.  
  3277. 15/11              251         double tilde, right hlf               ■ngalan
  3278.  
  3279. 15/12     1,5      252    ■    diacritic slash through char (LDS extension)
  3280. 15/13
  3281. 15/14     1,9      254    ■    high comma, centered                  g■eotermika
  3282. ANSEL Spacing graphic characters
  3283. 8-bit
  3284. C/R   wpcode    Dec  Graphic    Name              example of use
  3285. 10/0      
  3286. 10/1      1,152    161    ■    slash L - uppercase                   ■ód■
  3287.  
  3288. 10/2      1,80     162    ■    slash O - uppercase                   ■st
  3289.  
  3290. 10/3      1,78     163    ■    slash D - uppercase                   ■uro
  3291.  
  3292. 10/4      1,88     164    ■    thorn - uppercase                     ■ann
  3293.  
  3294. 10/5      1,36     165    Æ    ligature AE - uppercase               Ægir
  3295.  
  3296. 10/6      1,166    166    ■    ligature OE - uppercase               ■uvre
  3297.  
  3298. 10/7      1,6      167    ■    miagkii znak                          fakul■tet
  3299.  
  3300. 10/8      1,1      168    ■    middle dot                            novel■la
  3301.  
  3302. 10/9      5,28     169    ■    musical flat                          B■
  3303.  
  3304. 10/10     4,22     170    ■    patent mark                           ABC■
  3305.  
  3306. 10/11     6,1      171    ±    plus or minus                         A±B
  3307.  
  3308. 10/12     1,230    172    ■    hook O - uppercase                    B■
  3309.  
  3310. 10/13     1,232    173    ■    hook U - uppercase                    X■A
  3311.  
  3312. 10/14     1,11     174    ■    alif                                  Un■yusho
  3313. 10/15              175                                               reserved - future
  3314.  
  3315. 11/0      2,11     176    ■    ayn                                   fa■il
  3316.  
  3317. 11/1      1,153    177    ■    slash l - lowercase                   rozbi■
  3318.  
  3319. 11/2      1,81     178    ■    slash o - lowercase                   h■j
  3320.  
  3321. 11/3      1,79     179    ■    slash d - lowercase                   ■avola
  3322.  
  3323. 11/4      1,89     180    ■    thorn - lowercase                     ■annANSEL Spacing graphic characters (cont.)
  3324. C/R   wpcode    Dec  Graphic    Name              example of use
  3325.  
  3326. 11/5      1,37     181    æ    ligature ae - lowercase               skæg
  3327.  
  3328. 11/6      1,167    182    ■    ligature oe - lowercase               ■uvre
  3329.  
  3330. 11/7      1,16     183    ■    tverdyi znak                          ob■iavlenie
  3331.  
  3332. 11/8      1,24     184    ■    dotless i - lowercase                 masal■
  3333.  
  3334. 11/9      4,11     185    £    British pound                         £5.00
  3335.  
  3336. 11/10              186         eth
  3337. 11/11              187         reserved - future
  3338.  
  3339. 11/12     1,231    188    ■    hook o - lowercase                    S■
  3340.  
  3341. 11/13     1,233    189    ■    hook u - lowercase                    T■ D■c
  3342.  
  3343. 11/14              190         empty box (LDS-extension)
  3344.  
  3345. 11/15              191         black box (LDS-extension)
  3346.  
  3347. 12/0      6,33     192    ■    degree sign                           10■ C
  3348.  
  3349. 12/1      6,49     193    ■    script l                              25■.
  3350.  
  3351. 12/2      4,71     194    ■    phonograph cpyright mrk               Decca■
  3352.  
  3353. 12/3      4,23     195    ■    copyright mark                        ■1993
  3354.  
  3355. 12/4      5,27     196    ■    musical sharp                         D■
  3356.  
  3357. 12/5      4,8      197    ¿    inverted question mark                ¿Que
  3358.  
  3359. 12/6      4,7      198    ¡    inverted exclamtn mrk                 ¡Esta
  3360.  
  3361. 12/13              205         e in middle of line (LDS extension)
  3362.  
  3363. 12/14              206         o in middle of line (LDS extension)
  3364.  
  3365. 12/15     1,23     207    ß    Es Zet                                Preußen
  3366.  
  3367.