FTAnalyzer questions.

The file did also include the actual DOB as 06 JUL 1820 but I did not show that as I did not see that it was significant.

 

Recently updated FTA and pleased to see the plethora of additional reports available. The GEDCOM stats page lists quite a number of unknown fact types in my file. On looking at the "Data Errors" tab it appears that FTA does not like, or recognise, fact types that have been entered in upper case. I thought that it would be easy to go back and amend the originating source.

Unfortunately the source of the GEDCOM is Ancestry and the fact types are added when attaching the source and image to the individual. This is not editable within Ancestry's interface. The complicating factor is that Ancestry does not seem to be consistent in using upper or lower case. The vast majority of facts get entered as lower case and cause on problems in FTA but sometimes a fact will be entered in upper case even though there are many other instances of the same fact being entered in lower case. FTA only complains about the upper case instances.

Until Ancestry can be forced to get it's act together and enter all facts in lower case would it be possible to have FTA do a caseless check?

One other small issue is that Ancestry adds some images, school records for example, as a source of proof of residence. FTA then lists the residence fact in the data errors as "Residence date dd mmm yyyy is in a census year but doesn't overlap census date". This can, of course, be filtered out of the display.

 

I have been investigating this myself using a couple of instances of fact type "probate".

One instance shows within Ancestry like this:-



Another instance shows like this:-



As can be seen the first shows an editable field "Title" containing the fact "Probate" (lower case). This is populated by the attach command. The second instance shows no such field.

The GEDCOM entries for the two instances are thus:-

Code:

1 EVEN
2 TYPE Probate
2 DATE 14 JUL 1930
2 PLAC London, England
2 SOUR @S56@
 
1 PROB
2 DATE 20 FEB 1925
2 PLAC London, England
2 SOUR @S56@

The two probate entries are being recorded differently by Ancestry. One as a probate fact the other as a probate event. It is the event that is reported as an unknown fact and reported in upper case.

 

I could but there's 52 of them.

 

A frayed knot.

 

The vast majority are PROBATE or PROBATE DATE. There is one BURIAL and one UNSPECIFIED which was entered by Ancestry when attaching another probate entry.

 

Yes it has a date too.

Code:

1 EVEN
2 TYPE Probate Date
2 DATE 13 MAY 1938
2 PLAC London, England
2 SOUR @S56@

 

1. I have a few FUNERAL facts which are not being recognised by FTA. Please could that category be added to the acceptable list?
As an outsider, I don't understand the GEDCOM standard and would have expected Burial and Cremation, etc., to be sub categories of Funeral, or have I completely missed the point?

2. I have been using FTA to help me identify where similar Sources are used within a GEDCOM but then noticed that double clicking an entry in the Sources Report sometimes shows more instances than notified in the report. Why might that be? Am I falling foul of another option which is leading to double counting or are some instances not being included in the report count?

3. I am not sure how I should be stating occupation start and end dates because I am not getting what I expected. For instance the following GEDCOM records . . .

Code:

1 OCCU Baker
2 DATE  TO 04 NOV 1907
1 OCCU Soldier
2 TYPE full time
2 DATE  FROM 05 NOV 1907

produce BEF 04 NOV 1907 and AFT 05 NOV 1907 in FTA, which is close but not quite the same. Should I be recording this differently?
I gave 04 NOV 1907 as an end date and 05 NOV 1907 as a start date in my FHS to avoid overlap.

 

Correct. The Sources Report for a tree containing about 100 family members shows counts . . .

Source3 Cheshire Parish Records 5
Source4 Cheshire Parish Registers 18
Source12 Chester Parish Registers 23

but when I double click on Source4, a table is displayed with 20 rows.

Unfortunately, I have not always used the same terminology when recording this information and I have not found a way to update the Source record itself. Hence when I edit an individual's record to change the word "Records" to "Registers" a new instance is created rather than change it for all existing. This was a particular problem previously where I had some sources marked as Census events and some not.

Looking at the Source4 table I can see that there are 18 rows corresponding to 18 instances of "2 SOUR @S4@" in the GEDCOM file.
These are part of sections (level 1) relating to BIRTh, BAPtisM, DEATh, MARRiage, etc. That tallies with the Sources Report.

However, there are a further 4 instances of "1 SOUR @S4@" which are not so related. These appear as . . .

Code:

0 @ind00082@ INDI
1 NAME Surname /Forename/
2 GIVN Forename
2 SURN Surname
1 SEX F
1 EVEN
2 TYPE Lost Cousins
2 DATE 1841
1 BIRT
2 DATE 1788
2 PLAC Chester, Cheshire, England
1 BAPM
2 DATE 10 MAY 1791
2 PLAC St Oswald, Chester, Cheshire, England
2 SOUR @source00012@
1 DEAT
2 DATE 16 SEP 1847
2 AGE 59y
2 PLAC Great Boughton, Cheshire, England
2 SOUR @source00014@
2 NOTE Jul-Sep, Vol 19, Page 44.
1 SOUR @source00004@
1 CENS
etc

and seem to be the cause of the discrepancy.