Ancestris - Forum

Ancestris Support => ENGLISH => Topic started by: 1miss2mary3 on September 27, 2016, 06:10:41

Title: BIRTH PLACE - Conflicting dates or sources
Post by: 1miss2mary3 on September 27, 2016, 06:10:41
Under the GEDCOM format, the way to enter conflicting information from different sources is to duplicate a section of the GEDCOM record. The preferred version comes first and then the other conflicting ones hopefully with notes.
So in abbreviated form the GEDCOM record should look something like the following:

0 @I00002@ INDI
1 NAME Mary Tarsille /Marcotte/
2 GIVN Mary Tarsille
2 SOUR @S11@
3 QUAY 2
2 DATE ABT 1832
2 PLAC ,,,,,Canada
2 SOUR @S11@
3 QUAY 2
2 DATE 15 MAY 1832
2 PLAC ,,Cap-Sante,,Quebec,Canada
4 LATI 46.67159
4 LONG -71.78812
2 SOUR @S15@
3 QUAY 1

I realize this is something that is going to have to done through the GEDCOM editor.  But after I get the first version in, even in the GEDCOM editor, when I try to add a second BIRT section to the individual's record, it won't let me do it. When I right click on the individual to add another property, the property I want to duplicate is not on the list. The list only includes the properties which have not yet been used for that person. I think Occupation might stay listed allowing you to list different occupations at different points in a person's life, but I can't add an alternate birth date or alternate birth location.

Any ideas other than manually editing the GEDCOM file with NOTEPAD or another text editor for how to handle this situation? I'd really rather not stick all the information in the notes until I find the definitive source and documentation for every individual. I want to be able to keep track of my research and which source says what, especially when the GEDCOM standard has a way for doing it.

If Ancestris won't let me do this, any thoughts on another GEDCOM editor that will? This is likely a deal breaker for me on whether I can adopt Ancestris as my replacement program for the old one I've decided I have to give up because its not GEDCOM compliant enough for me and does not give me enough control over the GEDCOM file.
Title: Re: BIRTH PLACE - Conflicting dates or sources
Post by: arvernes on September 27, 2016, 07:11:57
From what i've understood, according to the gedcom specs, you can have one BIRTh tag only.
This is part of the gedcom specs :
  n[ BIRT | CHR ] [Y|<NULL>]  {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
    +1 FAMC @<XREF:FAM>@  {0:1}

As you can see, you must have one, but only one {1:1}
{ braces }
Indicates the minimum to maximum occurrences allowed for this structure or line% { Minimum:Maximum }.

For the gedcom specs, see there (
Title: Re: BIRTH PLACE - Conflicting dates or sources
Post by: 1miss2mary3 on September 27, 2016, 16:47:43
So maybe its one BIRT but two places or two dates.  I'll try that. Thanks for the suggestion.  Mary
Title: Re: BIRTH PLACE - Conflicting dates or sources
Post by: 1miss2mary3 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.
n @XREF:INDI@   INDI {1:1}
    +1 SEX <SEX_VALUE>   {0:1}
    +1 <<CHANGE_DATE>>  {0:1}

Substructures of the Lineage-Linked Form ...

  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.
Title: Re: BIRTH PLACE - Conflicting dates or sources
Post by: arvernes on October 05, 2016, 07:36:01
Hmmm, not sure about your interpretation. You can have multiple individual event structures according to the "{0:M}", but you can have one birth tag only  n[ BIRT | CHR ] [Y|<NULL>]  {1:1}
If you're not sure about a birth date, why don't you use the following structure :

DATE_VALUE: = {Size=1:35}
<DATE> |
You have "date_period", "date_range" "date_approximated", and even a "date_phrase".
I guess with all those possibilities, you can do what you want.
Just my point
I don't know if that helps. Francois