News on Data Doctors Report (Apr 29th 2018)

Question

News

In Privacy group added 4 new suggestions.

• 118 Still living in Death Location status with death date
• 119 Still living in Death Location status with death location
• 120 Still living with death date
• 121 Still living with death location

They identify profiles, that have colliding data defining living status of a person.

Challenge

* https://www.wikitree.com/wiki/Space:DD_Challenge_Death_Dates_and_Locations

Answer 1

Thanks for adding those new error types, Aleš.

I have an unrelated question for you. One of "my" data doctors reports included an findagrave "error" that I had marked as a false error in June 2017, but reappeared in the report because another member added a comment recently (their comment confirmed my conclusion that there is no identifiable basis for the date given on findagrave). I've marked it "false error" again, and I hope the error doesn't come back again. But now I want to know if there are some types of events that cause old hidden errors to reappear. Or is this probably just a case of a conscientious data doctor re-reviewing old hidden errors?

Comments

I would like to know too. I suspect that the error is re-tested and may come back each time the field was edited.

Very unpleasant experience with a French notable who has an incorrect birth date in Wikipedia, and Wikidata as well. I took the trouble of correcting both, providing a full reference of the birth record. Someone later put the wrong date back without even bothering to remove my source. Ugh. I gave up on Wikidata and put up a very obvious warning message on the WikiTree profile to help prevent it being "fixed". (it is the General de Gaulle's brother).

---

I consider the latest entry for a suggestion as active. So if someone comments after your False error, it behaves according to that comment. You should just mark it as false again. The comment probably came from correcting another suggestion on this profile.

Answer 2

They still need to stop flagging French and Italian names. That's all I'm gonna say.

It gets really annoying when I get a message every once in a while saying "Possible incorrect spelling" for a French Canadian or Italian person's name. Got a few today and it just makes my eyes roll. So I hide the "errors" forever.

Comments

I get a warning "incorrect gender" for men named Jean. Just sayin'.

---

I get misspellings for Francescoantonio!!

---

I have 242 False Suggestions for unique names in my watchlist... examples include "Jean-Philippe Léo", "Jean Pierre Hélie", "Françoise-Thérèse", "Julie Françoise", "Anne Marie Renée", etc.

---

I get them for French names and last names like Dussault, Laplante etc. C'est incroyable! I think that's how you say it in French.....

---

Yes that's how we say it... I don't think it tests family names, but any name combination that does not exist a minimum of times in the database gets flagged as "unique". This minimum threshold thing doesn't work for gender though, unfortunately. I still get errors for all women named Claude.

---

That's just bizarre. Hopefully the Data doctors will look into this and fix it for our sanity's sake. Those are the most common "errors" I keep getting.

---

For suggestion 511 Program checks only for name combinations, that appears only once. so "Jean-Philippe Léo" appears only once on wikitree. And for those each word is checked  and if they all appear more than 5 times it is also ok. 

So according to http://wikitree.sdms.si/default.htm?report=ana1&FirstName=Jean-Philippe+Léo&MaxNames=500 this name shouldn't be marked as a suggestion. Maybe at some point in the past, but not now. Can you give me the WikiTreeID, so I can check.

For gender suggestions, it is determined by sampling the data. For Claude numbers are like this. http://wikitree.sdms.si/default.htm?report=ana1&FirstName=Claude&MaxNames=500

Claude appears 3604 times and 3217 of them are male and 126 are female.

---

My bad, Jean-Philippe Léo has a stage name which I put in the Nicknames field and that's probably what triggers the error. His ID is Clerc-31.

I'm glad gender is determined by percentage, it means when we have enough female Claude (the name is absolutely unisex in France) it will stop being an error.

---

In suggestion report you can click the link over names

 

511 Unique names (spelling)	Clerc-31  H		Jean-Philippe Léo Johnny Hallyday Smet (Clerc)		1943-06-15 Paris IX, Paris, Seine, France	2017-12-05 Marnes-la-Coquette, Hauts-de-Seine, France	Male		WikiTree-56 Rassinot-1

and you will get this report

http://wikitree.sdms.si/function/WTWebNameDistribution/errors.htm?FirstName=Jean-Philippe%20L%C3%A9o%20Johnny%20Hallyday&MaxNames=100

Each name is analysed and you can see, that Hallyday is the unique one. So it is the name that has a typo or is really unique. it is the only one on WikiTree.

---

Oh, thanks. Yes, Hallyday is the unique name, and it is really an" other family name" (aka) which I put in the nickmanes field for better display.

---

I second Isabelle's comment, Claude is non-gender specific here  in Québec also.

Also had someone come along and ''correct'' capitalization on a location name.  île de Montréal for example (forget actual placename this happened on), takes a capital only on Montréal.  Cut back some of these ''errors'' please, the fantasy names that are seldom seen were in fact written that way often, don't know how often it's come up on some of mine.  People writing phonetically with no ''standard'' spelling back then.

Answer 3

There and new suggestions. They are/will be added also to the challenge, so they will count. Now I will go to sleep and finish the reports in the morning.

78249 Suggestions	Total	0000-0000
Date
131 No Dates - Open - Conflicting Dates on relatives	45864	45864
132 No Dates - Open - No Dates on relatives	78249	78249
133 No Dates - Open - Dates on relatives	350000	350000

This are new suggestions to correct. This are all open profiles without birth and death date. You can all edit all of these. The goal is to define dates. 

In 133 suggestion, there is approximate date in info column based  on relatives +- 20 years, so those should be easyer to correct.

for 131 and 132 are no birth dates in nuclear family, so you should check further in relations.

Aleš

Comments

In the 131 bucket, I found https://www.wikitree.com/wiki/Alvarez-903 . The data qualifier on the death date is "About/uncertain but non-living." According to Jamie Nelson, that data qualifier is supposed to prevent a person from being treated as Living or changed to "Unlisted." Profiles like that one would benefit from having dates added, but they should not be high priority to fix at the moment. Can these error sets be filtered to pull out profiles with that data qualifier?

---

On profiles with that qualifier, only profile manager and the Team can edit, so there is no point in making those profiles part of the challenge (errors 120 ans 121).

130 suggestions help in determining when those people lived, and that info can be extrapolated to relatives. Abby just found one line with 20 undated generations. And it is very timely to find the dates in relatives.

---

I would also like to point out the TREE icon under the wikitreeid link on all reports.

Allardyce-14
 H

It takes you to nuclear family chart where all profiles are positioned in the timeline, so you can see where the date problems are or where the dates are entered.

Try it out on some person you are familiar with, so you will understand the chart.

---

That "About/uncertain but non-living" data qualifier appears on numerous Open profiles, which can be edited by anybody. Its use is not limited to Private profiles.

Many of the profiles that lack dates (including a number of profiles that I've adopted) are Unsourced -- and sometimes nearly empty -- profiles created by gedcom imports in 2010 and 2011. I've looked at several case where one or two children in a large family lack dates. If the rest of the children were born between 1660 and 1682, it's pretty clear that the child is long dead, but "estimating" a specific birth date for such as child is essentially making up data -- inserting the child into the family's birth sequence in a place that may be incorrect. I'm reluctant to estimate a specific date for a child who may have died young -- or may not have existed, particularly in the pre-1500 and pre-1700 time periods. I'd rather have the database say "He's dead."

---

I confused the qualifiers. You are correct. Those could be removed from the reports. It takes almost a day to redo the report. Is there significant number of those?

---

In the small number of these errors I've looked at, only about 10% had that qualifier. However, I've been adding the qualifier to other profiles, when it is obvious the person is dead and the research to find specific dates isn't easy.

---

For one profile I reviewed with one of these codes, my edits included adding the "Uncertain Existence" template. It occurs to me that profiles marked "Uncertain Existence" are another group that does not need to be treated as living people whose privacy needs to be protected.

---

Changed. See the other answer.

Answer 4

Am I reading the Spreadsheet correctly?  One tab shows the difference from previous weeks.  And by far the most "new" errors are related to profiles with "Still Living" but with death date or location information.  Is that typical, or just a post C-A-T artefact?  If it is real, then it would seem like something Wikitree techs could fix by adding a test when profiles are being saved.

Comments

Those are new errors, that the team needs to fix due to new european legislation. they were created this week, so they are all new. Next week it will show the actual difference.

Answer 5

Hi Ales, I checked my suggestions and discovered an Error 133 on a profile that had an estimated date (1580 about/uncertain). I've marked as a false error, but was surprised that it generated an error. There will be a lot of profiles in this situation presumably.

Comments

Of course it had a date. You entered it today. See the change log.

So if you correct a suggestion, mark it as corrected, not false error.

---

Ok. I see now. It was Allen-10230, but I’d added the date two days before I checked the suggestions list, so since the last report. Thanks

---

Suggestions list are always based on weekly database dump made on sundays.

Answer 6

https://www.wikitree.com/wiki/Category:Estimated_Dates

{{Estimated Date|Death '''(based on REASON)'''}}

This sticker can be changed to birth or marriage also but the important thing is to put the REASON in so people seeing the sticker will know why there is an estimated date.

Comments

The only allowed parameters for Estimated Date template are this.

• {{Estimated Date|Death}}
• {{Estimated Date|Marriage}}
• {{Estimated Date|Birth and Death}}
• {{Estimated Date|Birth and Marriage}}
• {{Estimated Date|Death and Marriage}}
• {{Estimated Date|Birth Death and Marriage}}

Anything else result in new suggestion to correct.

 

You should add a reason after the template.

{{Estimated Date|Death}}  '''(based on REASON)'''

Answer 7

Working on 556: Wikidata - empty death date.

Why the listed match between Reiss-11 and Q6216444 ?  (This is the only entry in the timeframe 2000-9999 in the Suggestions report.)

Comments

The correct profile is

https://www.wikitree.com/wiki/Rei%C3%9F-11

instead of

https://www.wikitree.com/wiki/Reiss-11

obviously some error in profile identification. I will look into it.

---

There were a few more wikidata errors connected to ss vs ß I corrected the error so it shouldn't show in the future.

Answer 8

Added 4 new suggestions for open profiles without any date

I think this will be the final version of 130 suggestions. 131 and 133 are errors while 132 and 134 are warnings. Help pages are updated. to new suggestions.

Suggestions	Total	0000-0000	0001-1499	1500-1699	1700-1799	1800-1899	1900-1999	2000-9999	Open	New
Date
131 No Dates - No Dates on relatives - Open - Unknown Status	116060	116060							116060
132 No Dates - No Dates on relatives - Open - Status Died	8017	8017							8017
133 No Dates - Dates on relatives - Open - Unknown Status	321812	321812							321812
134 No Dates - Dates on relatives - Open - Status Died	36707	36707							36707