home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / f / fhs01.zip / MANUAL.ZIP / APENDIXC.DOC < prev    next >
Text File  |  1992-05-05  |  5KB  |  125 lines
  1.  
  2.  
  3.  
  4.       Appendix C. Date Status Fields and Adoptive Relationships
  5.  
  6.       I will try to explain in this section the purpose of several `status'
  7.       fields which have been added to the NAME record information.  Each
  8.       field appears as a one character extension to the right of the Birth &
  9.       Death dates and Mother & Father ID numbers in the NAME information
  10.       view in the file maintenance program (Main Menu option F1).
  11.  
  12.       For the Birth & Death date fields, these status indicators permit you
  13.       to assign 3 different levels of `assurance' regarding the accuracy of
  14.       the dates shown.  Symbols recognised in these fields are "!", " ",
  15.       and "?".  The "!" symbol would indicate a date backed by a primary
  16.       source of information (this can mean whatever you want it to, but
  17.       might include a `birth' or `death' certificate or family Bible
  18.       entry).  A blank (" ") would indicate a secondary source such as a
  19.       document whose own source is not known, and a "?" would indicate a
  20.       questionable source of information (such as a computed date from
  21.       vague recollections).  Explanations for the choice of symbols could
  22.       be included in the comments for the individual's name record.  These
  23.       symbols are displayed in all reports produced.
  24.  
  25.       The status fields appearing to the right of the mother and father ID
  26.       numbers may be used to indicate that a parent-child relationship is
  27.       an adoptive one or is questionable (for example when it is uncertain
  28.       which of the spouses of an individual parented a child).  The symbols
  29.       recognized by the program are "*" for an adoptive relationship and
  30.       "?" for one whose information is uncertain.  Descendant reports may
  31.       optionally include or exclude adopted individuals and their
  32.       descendants, and if included, the relationship is marked with an "*"
  33.       in the bloodline next to the entry corresponding to the adoptive
  34.       relationship.
  35.  
  36.       Perhaps a few remarks might be in order to try to explain my reason
  37.       for treating adoptive relationships as I have.  When I first began
  38.       designing the formats for the Family History files, I intended
  39.       allowing for maintaining a complete history of both biological and
  40.       adoptive parent/child relationships.  However, because of the
  41.       complexity of handling the record of adoptions, which could
  42.       conceivably involve one or more `parents' singly or in pairs, and
  43.       because of the relative rarity of the situation, the limit of my
  44.       commitment was allowing for a `pointer' field to an un-implemented
  45.       adoption record.
  46.  
  47.       As I have worked on adding information to my own family files from an
  48.       extensive list of descendants of a 7th generation ancestor, gathered
  49.       through the dedicated efforts of a distant cousin, I have been
  50.       repeatedly faced with the decision of how to treat children who are
  51.       identified as being adopted.  In all cases, I had chosen to omit
  52.       establishing the parent/child relationship.  However, I was troubled
  53.       by the thought that such individuals would be left out of reports
  54.       which would include "siblings" with whom they shared a common
  55.       traditional heritage, if not a biological one.  I did notice, though,
  56.       that in the information I had, the `missing' biological parent was
  57.       seldom indicated; therefore, I opted for an alternative approach to
  58.       the `adoption problem' which would permit including an adoptive
  59.       relationship and would allow producing reports which would optionally
  60.  
  61.  
  62.                                       85
  63.  
  64.  
  65.  
  66.       include or exclude information for such relationships, but which
  67.       forces one to decide, when full information is available, whether to
  68.       record a biological or `traditional' ancestry for an individual.
  69.       Though I am not entirely satisfied with this approach, I feel that it
  70.       is an improvement over the previous situation.
  71.  
  72.       I do have plans for providing a more complete treatment of adoptive
  73.       relationships in a future update.  It may be possible to include this
  74.       within the current file design, by providing "alias" name records, or
  75.       it may be part of a planned redesign of the file format.  I would be
  76.       interested in receiving any remarks you may care to make about what
  77.       you expect in the treatment of adoptive information.
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.                                       86
  125.