Conrad Heinrich Rixe Male 22 August 1806 – Deceased • K4KS-8R3

Dean, Barton David

Following is the discrepancies noted in the Conflict-Free Data section:

• The date of birth +1806-08-22 is in conflict with the standardized place Schildesche, Bielefeld, Westphalia, Prussia, Germany, which existed from +1878 to +1946.
• The date of christening +1806-08-24 is in conflict with the standardized place Schildesche, Bielefeld, Westphalia, Prussia, Germany, which existed from +1878 to +1946.

My Comment: There is no standardized option to choose from prior to the year 1816. Conrad was born and christened in 1806.

Source Consistency Issue:

• Conrad Henrich Rixe, "Germany Births and Baptisms, 1558-1898" has a place of Altstadt, Osterode, Ostpreußen, Preußen for birth, which is different from Schildesche, Westphalia, Prussia.

My Comment: Extracted transcripts are not always complete or accurate. In this instance, I might have not read correctly, but I believe I saw the abbreviation "geb." meaning he was born in Schildesche. What do he enter: his current residence or his place of birth? I also see numerous instances, this record included, where both births and baptisms are recorded in the parish register, but only one of them is given. I then See a duplicate where the other one is given. I do struggle with standardization because I occasionally encounter instances where there are no standardized options for event dates such as births, baptisms, marriages, deaths, or burials. I am using this space to see if software developers hear of people such as myself experience similar challenges. On the whole I love the changes being made and tend to thing developers and do anything. When new persons are created, I wish we had the option to choose between births and baptisms and deaths and burials. They are not the same thing nor do the normally take place on the same date. It has caused issues for others editing my family tree with merges and non-matches with people having same or similar names.

Gordon Collett

That is one concern that I have had for a while, that the Data Quality Index does not state clearly enough that it is pointing out errors both in a profile and in the indexes. In fact, it seems from the reports printed here that when the routine points out a problem, it is actually much more likely to be an error in the index, sometimes even in the original source itself, or to reflect the incompleteness of the Places database than to be a problem on the profile.