1
ENGLISH / Re: BIRTH PLACE - Conflicting dates or sources
« on: September 27, 2016, 20:10:40 »
No, one BIRT with multiple PLAC did not work. So I went back to read the specifications closer. What I quote below is long, but necessary since the specifications are very long winded. The specifications very clearly say that to represent conflicting information on birth, for example, you do wind up using the BIRT tag multiple times in one individual's record, but you must do so by repeating the entire <<INDIVIDUAL_EVENT_STRUCTURE>> not just the BIRT tag line. You would have to repeat the following for each conflicting source on the individual's birth:
n[ BIRT | CHR ] [Y|<NULL>] {1:1}
+1 <<EVENT_DETAIL>> {0:1}
+1 FAMC @<XREF:FAM>@ {0:1}
But my point here is that the GEDCOM specifications do provide for multiple conflicting birth information within the same individual. So my question remains - how do you input this using Ancestris' GEDCOM editor?
--------Relevant sections of GEDCOM 5.5 specifications - Long ---------------------------------------------------
Chapter 2 ...
The following symbols are used in Chapter 2: ...
{ braces }
Indicates the minimum to maximum occurrences allowed for this structure or line% { Minimum:Maximum } . Note that minimum and maximum occurrence limits are defined relative to the enclosing superior line. This means that a required line (minimum = 1) is not required if the optional enclosing superior line is not present. Similarly, a line occurring only once (maximum = 1) may occur multiple times as long as each occurs only once under its own multiple-occurring superior line. ...
Lineage-Linked Form Usage Conventions
The order in which GEDCOM lines are written to a GEDCOM file is controlled by the context and level number. ... The occurrence of equal level numbers and equal tags within the same context imply that multiple opinions or multiple values of the data exist. The significance of the order in these cases is interpreted as the submitter's preference. The most preferred value being the first with the least preferred data listed in subsequent lines by order decreasing preference. For example, a researcher who discovers conflicting evidence about a person's birth event would list the most credible information first and the least credible or preferred items last.
Systems that support multiple fields or structures should allow their users to indicate their preference opinion. Systems that only store single value structures should use the preferred information (the first occurrence listed) and store the remaining information as an exception, preferably within an appropriate NOTE field or in some way that the patron has ready access to the less-preferred data when viewing the record.
Conflicting event dates and places should be represented by placing them in separate event structures with appropriate source citations rather than by placing them under the same enclosing event.
...
INDIVIDUAL_RECORD: =
n @XREF:INDI@ INDI {1:1}
+1 RESN <RESTRICTION_NOTICE> {0:1}
+1 <<PERSONAL_NAME_STRUCTURE>> {0:M}
+1 SEX <SEX_VALUE> {0:1}
+1 <<INDIVIDUAL_EVENT_STRUCTURE>> {0:M}
+1 <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> {0:M}
...
+1 RIN <AUTOMATED_RECORD_ID> {0:1}
+1 <<CHANGE_DATE>> {0:1}
...
Substructures of the Lineage-Linked Form ...
INDIVIDUAL_EVENT_STRUCTURE: =
[
n[ BIRT | CHR ] [Y|<NULL>] {1:1}
+1 <<EVENT_DETAIL>> {0:1}
+1 FAMC @<XREF:FAM>@ {0:1}
|
n [ DEAT | BURI | CREM ] [Y|<NULL>] {1:1}
+1 <<EVENT_DETAIL>> {0:1}
...
n EVEN {1:1}
+1 <<EVENT_DETAIL>> {0:1}
]
The EVEN tag in this structure is for recording general events or attributes that are not shown in the above <<INDIVIDUAL_EVENT_STRUCTURE>>. The general event or attribute type is declared by using a subordinate TYPE tag to show what event or attribute is recorded. For example, a candidate for state senate in the 1952 election could be recorded:
1 EVEN
2 TYPE Election
2 DATE 07 NOV 1952
2 NOTE Candidate for State Senate.
n[ BIRT | CHR ] [Y|<NULL>] {1:1}
+1 <<EVENT_DETAIL>> {0:1}
+1 FAMC @<XREF:FAM>@ {0:1}
But my point here is that the GEDCOM specifications do provide for multiple conflicting birth information within the same individual. So my question remains - how do you input this using Ancestris' GEDCOM editor?
--------Relevant sections of GEDCOM 5.5 specifications - Long ---------------------------------------------------
Chapter 2 ...
The following symbols are used in Chapter 2: ...
{ braces }
Indicates the minimum to maximum occurrences allowed for this structure or line% { Minimum:Maximum } . Note that minimum and maximum occurrence limits are defined relative to the enclosing superior line. This means that a required line (minimum = 1) is not required if the optional enclosing superior line is not present. Similarly, a line occurring only once (maximum = 1) may occur multiple times as long as each occurs only once under its own multiple-occurring superior line. ...
Lineage-Linked Form Usage Conventions
The order in which GEDCOM lines are written to a GEDCOM file is controlled by the context and level number. ... The occurrence of equal level numbers and equal tags within the same context imply that multiple opinions or multiple values of the data exist. The significance of the order in these cases is interpreted as the submitter's preference. The most preferred value being the first with the least preferred data listed in subsequent lines by order decreasing preference. For example, a researcher who discovers conflicting evidence about a person's birth event would list the most credible information first and the least credible or preferred items last.
Systems that support multiple fields or structures should allow their users to indicate their preference opinion. Systems that only store single value structures should use the preferred information (the first occurrence listed) and store the remaining information as an exception, preferably within an appropriate NOTE field or in some way that the patron has ready access to the less-preferred data when viewing the record.
Conflicting event dates and places should be represented by placing them in separate event structures with appropriate source citations rather than by placing them under the same enclosing event.
...
INDIVIDUAL_RECORD: =
n @XREF:INDI@ INDI {1:1}
+1 RESN <RESTRICTION_NOTICE> {0:1}
+1 <<PERSONAL_NAME_STRUCTURE>> {0:M}
+1 SEX <SEX_VALUE> {0:1}
+1 <<INDIVIDUAL_EVENT_STRUCTURE>> {0:M}
+1 <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> {0:M}
...
+1 RIN <AUTOMATED_RECORD_ID> {0:1}
+1 <<CHANGE_DATE>> {0:1}
...
Substructures of the Lineage-Linked Form ...
INDIVIDUAL_EVENT_STRUCTURE: =
[
n[ BIRT | CHR ] [Y|<NULL>] {1:1}
+1 <<EVENT_DETAIL>> {0:1}
+1 FAMC @<XREF:FAM>@ {0:1}
|
n [ DEAT | BURI | CREM ] [Y|<NULL>] {1:1}
+1 <<EVENT_DETAIL>> {0:1}
...
n EVEN {1:1}
+1 <<EVENT_DETAIL>> {0:1}
]
The EVEN tag in this structure is for recording general events or attributes that are not shown in the above <<INDIVIDUAL_EVENT_STRUCTURE>>. The general event or attribute type is declared by using a subordinate TYPE tag to show what event or attribute is recorded. For example, a candidate for state senate in the 1952 election could be recorded:
1 EVEN
2 TYPE Election
2 DATE 07 NOV 1952
2 NOTE Candidate for State Senate.