News on Database errors project (29 May 2016)

Question

Analysis was done on data from May 29th 2016.

In 7 days 14781 errors were corrected by my estimation. Great job.

Have fun correcting errors.

You can also join the project here: http://www.wikitree.com/wiki/Project:Database_Errors

	22.5.	Projected	29.5.	Reduction	Delta%
101 Birth in future	253	254	242	12	4,77%
102 Death in future	313	314	307	7	2,35%
103 Death before birth	13022	13079	12774	305	2,33%
104 Too old	6968	6999	6930	69	0,98%
105 Duplicate sibling	3026	3039	2876	163	5,37%
106 Duplicates between bigtree and unconnected	2959	2972	2965	7	0,24%
107 Full name in UPPERCASE	3136	3150	3088	62	1,96%
108 Full name in lowercase	3193	3207	3193	14	0,44%
109 Profile should be open (birth date)	11439	11489	10853	636	5,54%
110 Profile should be open (death date)	1512	1519	1481	38	2,48%
201 Father is self	114	115	112	3	2,18%
202 Parents are same	98	98	79	19	19,74%
203 Father is Female	6253	6280	6376	-96	-1,52%
204 Father has no Gender	1026	1031	954	77	7,42%
205 Father is too young or not born	48607	48820	48653	167	0,34%
206 Father is too old	6789	6819	6775	44	0,64%
207 Father is also a child	378	380	375	5	1,23%
208 Father is also a spouse	216	217	208	9	4,12%
209 Father is also a sibling	3078	3092	2967	125	4,03%
210 Father was dead before birth	32506	32649	32447	202	0,62%
301 Mother is self	5	5	8	-3	-59,31%
303 Mother is Male	7798	7832	7333	499	6,37%
304 Mother has no Gender	1540	1547	1074	473	30,56%
305 Mother too young or not born	65559	65845	65553	292	0,44%
306 Mother is too old	5716	5741	5685	56	0,97%
307 Mother is also a child	11	11	12	-1	-8,62%
308 Mother is also a spouse	1322	1328	1186	142	10,68%
309 Mother is also a sibling	356	358	351	7	1,83%
310 Mother was dead before birth	31067	31203	30892	311	1,00%
401 Spouse is self	3	3	2	1	33,61%
402 Unknown gender of spouse	2068	2077	1742	335	16,11%
403 Single sex marriage	3502	3517	2156	1361	38,69%
404 Marriage before birth	10526	10570	10560	10	0,09%
405 Married too old	2812	2824	2769	55	1,94%
406 Marriage after death	12506	12558	12074	484	3,86%
407 Death too old after Marriage	1659	1666	1605	61	3,66%
408 Multiple marriages on same day	10198	10241	10011	230	2,24%
409 Marriage to duplicate person	31772	31904	31338	566	1,78%
501 Wrong male gender	8813	8852	8515	337	3,80%
502 Missing male gender	74800	75128	74330	798	1,06%
503 Probably wrong male gender	6147	6174	6389	-215	-3,48%
504 Probably missing male gender	35644	35801	35693	108	0,30%
505 Wrong female gender	10295	10340	9699	641	6,20%
506 Missing female gender	60375	60640	59697	943	1,56%
507 Probably wrong female gender	5260	5283	5575	-292	-5,53%
508 Probably missing female gender	29382	29511	30243	-732	-2,48%
509 Missing gender	96390	96813	95072	1741	1,80%
510 Unique name without gender	23454	23557	23373	184	0,78%
511 Unique name (spelling)	283116	284359	293826	0	0,00%
512 Separators in first name	68383	68683	68177	506	0,74%
601 Unknown birth location	9392	9440	9003	437	4,63%
604 Birth location too short	13986	14057	13796	261	1,86%
605 Number in birth location	1933	1943	1764	179	9,20%
631 Unknown death location	16509	16593	16198	395	2,38%
632 Y death location	6355	6387	5662	725	11,36%
634 Death location too short	17071	17158	16033	1125	6,56%
635 Number in death location	1625	1633	1239	394	24,14%
661 Unknown marriage location	1348	1355	1350	5	0,36%
664 Marriage location too short	3020	3035	2802	233	7,69%
665 Number in marriage location	228	229	11	218	95,20%
901 Unconected empty public profiles	35346	35501	35432	69	0,19%
902 Unconected empty open profiles	17136	17211	17235	-24	-0,14%
Total	1159314	1164434,519	1159120	14781	1,27%

Comments

Thank You Aleš ! I fixed some of my oversights & will repair the rest ASAP= As Soon As Possible. :)

---

This is great; and I bet the number of fixes is higher because in the process we tend to fix profiles associated with the one in question. At least some of us do.

---

Increase is mainly result of added menu link to errors page. I think each day a few people learens abor errors and fixes the ones connected to them.
But you made a good point to correct also connected profiles. One merge can create a lot of new errors, if both profiles have same relatives that also needs to be merged.

Answer 1

Thank you for bringing the errors to us....I will do my part and join everyone that are interested in this project. I will start by looking at my line and then move to others.---Lise

Answer 2

Thanks.

WATCHLIST: I tried the watchlist option and it works.  It includes "errors" (mother too young, etc.) that are based on connections to profiles that are not on my watchlist.  That's OK, and I'm not saying anything needs to be changed; just wanted to mention that it is not limited to errors in profiles for which we are PM/TL.

 

FALSE ERROR: is that supposed to be used only when it is a SYSTEM MISTAKE, or is it also OK to use TO SUPPRESS future error reporting when the supposed "error" is not an actual error and we can't fix it because we don't have any better data to justify a change, for things like estimated birth or death date.

Comments

In relation errors, both profiles are listed as an error, since one of them has a problem. It is so by design and will remain so.

False errors are meant to hide error for everyone, so use it only if data is correct and the error shouldn't appear. (Gender with dead born children, name with dead born twins, and other errors, that can very rarely be true,...) False errors will never appear again, so use it when sure. Estimated dates can be better estimated.  One can not be father at the age of 3.

---

You missed a key point on date estimates. Not all can be improved.  People don't always agree on what the estimate should be.  I'm not going to change a profile I manage because another PM has a poor estimate with no evidence or rational to support it, and it's not worth starting an argument with them.  And I would not be happy if someone changed my estimate to better fit with a bad one.

---

Re Mikey Anonymous
 

Suggestion: Add a Research Notes section and explain how you did your estimate.... then the next person understands that someone has thought and this is a good estimate ;-) .....

You can also Mark False Error ==> that error number will not appear again connected to this WikiTree profile

Answer 3

Have noticed a small problem this evening. I'm working on error code 106, for 1900-1999 and have been using the temp hide since it was implemented. And all those that I 'hid' from the 15th May report had disappeared by 22nd May, which was as expected and very welcomed. However they have all reappeared on today's report. They've only been hidden for two weeks, rather than the promised 30 days, and this also explains why the totals of errors outstanding hasn't decreased this week although the merges are still being raised. (I've currently got 143 merges awaiting default approval). Would be grateful if this could be looked at, as this feature is very useful for those of us raising merges.

Comments

Fixed.

---

Thank you Aleš, for the prompt response and resolution, it was very much appreciated.

---

Thank you, Aleš.

Answer 4

Refined date conditions

Now i correctly compare all uncomplete dates (Decade with private profiles, Year without month and day and Year and month without day) so there are no longer false errors with error 101, 102, 103, 104, 109, 110, 205, 206, 210, 305, 306, 310, 404-407 so number of errors slightly changed for these errors.

Answer 5

New errors: 606, 636, 666 Bogus location

606, 636, 666 Bogus location: This location is inserted as location by autocomplete operations of some softwares or websites.

 

Errors	Total	0000-0000	0001-1499	1500-1699	1700-1799	1800-1899	1900-1999
606 Bogus birth location	58	10	4	31	5	8
636 Bogus death location	980	45	178	288	327	141	1

 

Comments

It's not completely clear to me what this means or what if anything the db_errors volunteers are expected to do about it.  Are "Somme ... France" and "Sea ... Indonesia" examples of the errors?  So then, "Sea ..." should just be "at sea", and "Somme ..." probably was entered as "some where" or "some place" and therefore should just be removed.  Or am I totally off-track?

---

Re Mickey Anonymous

My understanding this is Genealogy 2016 ;-)

Y is added in e.g. Ancestry.com as Death location and the Acestry software expands it to   Y, Somme, Picardie, France

See ancestryforums

---

• G2G topic on this subject how come these swedes were born in y somme picardie france 
• Blog http://ysommepicardiefrance.blogspot.se/

---

And for Sea Sulawesi:

* http://boards.ancestry.com/surnames.brumback/65.1/mb.ashx

and for Reusel de Mierden:

* http://www.dutchgenealogy.nl/ancestors-in-reusel-de-mierden-noord-brabant/