home *** CD-ROM | disk | FTP | other *** search
/ Shareware 1 2 the Maxx / sw_1.zip / sw_1 / GENEFILE / FHS1.ZIP / MANUAL.ARC / APENDIXC.DOC < prev    next >
Text File  |  1988-09-22  |  5KB  |  123 lines

  1.  
  2.  
  3.  
  4.       Appendix C. Notes on Adoptive Relationships & Date Status Fields
  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 on 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.  
  60.  
  61.                                      57
  62.  
  63.  
  64.  
  65.       relationship and would allow producing reports which would optionally 
  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 would still like to provide a more complete treatment of adoptive 
  73.       relationships but this would now require changes to the file format 
  74.       that would make it incompatible with previous versions of the system.  
  75.       Of course the export/import program of the extended system could 
  76.       provide a means for converting between the two formats but still, I 
  77.       don't expect to accomplish this any time soon.
  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.                                      58
  123.