Did you notice the data validation changes?

Question

Hi WikiTreers,

We just released some improvements to our "data validation" systems, i.e. the checks for conflicting or questionable data that we do when creating or editing a profile.

(We actually tried to release the changes earlier today but K Bloom and some other members spotted problems so we pulled back and made some quick changes. Thank you to those who reported the bugs.)

For those who are interested, here's the current list of checks: https://www.wikitree.com/wiki/Help:Data_Validation

The most significant change today is that the error messages are much more informative.

For example, prior to this you might see error messages such as, "A birth date should not be more than 60 years before or after a sibling's birth date" or "A child's birth date should not be before a parent is six years old."

With these messages, you would have no idea which date for which sibling was causing the problem, or with parent-child problems, even whether the profile you were editing was the parent or the child in the relationship. This could be very frustrating.

Now the error messages will say something like, "A birth date (Whitten-964 born 1900) should not be more than 60 years before or after a sibling's birth date (Whitten-1 born 15 Sep 1971)" or "A child's birth date (Whitten-964 born 1900) should not be before a parent is six years old (Jones-1 born 17 Nov 1947)."

In addition to the error message improvements, we added a lot of checks regarding conflicting indicators on whether or not the person is living. These are very important because they affect our privacy controls. These checks should help prevent profiles from being locked-up unnecessarily.

Please post here if you spot any problems. It's certainly possible that there are more bugs. Thanks!

Onward and upward,

Chris

Comments

Easier to have a number combined with the error message. Easier to communicate and report problems.

In the same way as Aleš has Data Error 911 - Swedish patronym DOTTER for male and lesson learned from the DB error is that it fast get complex and people has opinion on names/descriptions... Aleš now have +200 errors and without numbers its impossible to administrate and write help pages...

• Category:DBE_Error

Lists comparing Wikitree errors and DBE errors is also easier saying DB 512 = WikiTree 432 etc.... 

---

Error: Invalid data. The following must be corrected:

1. This person has data indicating they are both living (Death Place 'still living') and not living (Death Date 1742-02-00, Death Date 'non-living', Death Place Lanoraie, Canada, Nouvelle-France, Age = 321).

I get the above on a profile I am editing, trying to save it.  Utter nonsense, sorry, but not marked as still living at all.

https://www.wikitree.com/index.php?title=Baudry-15&action=edit&errcode=merge_complete

---

Hi Chris, just as a matter of interest towards data validation, please see my comment https://www.wikitree.com/g2g/506707/did-you-notice-the-data-validation-changes?show=508469#c508469.

---

ok, found the problem, please either remove the ''death place still living'' button or move it totally out of the way.  It is actually redundant, if a person is marked as still living in the date box.

---

Thank you!

---

I am getting the same message every time I try to enter a new person.  He form is defaulting to Living and there is no way to Un check it, so the conflicting error messag.  I can’t enter any new Ancestors

---

Always improving - WikiTree is amazing and so are you Chris.

Thank you for the more specific error messages, and for all the improvements you make to WikiTree.

Gratefully,

April Dellinger Dauenhauer

Answer 1

Thank you Chris, for all the things you do to make our Wikitree life simpler, and the care you take when implementing changes and updates.

Comments

Thanks, Wendy. That's very nice of you to say. :-)

Answer 2

Thanks for the new  validation.   It will really help.

Answer 3

Thanks, Chris!

Answer 4

it said that the name Mirillia was too weird,just because it is a rare name...

Answer 5

Thanks Chris, it’s a much appreciated improvement.

I think I might have noticed this working on a profile today, when it was telling me I had a mismatched <ref > thought maybe I hit some boundary condition with 32 ref in the profile. Several tries later, no changes, it worked. Just my knack for testing software....

Answer 6

I do not know if it is related to these changes, but I had the following problem today.

 

I have a marriage for which I have a divorce date, but not the marriage date.  I was able to create the wife's profile, with a birth date and a "marriage end" date, but no marriage date.

 

But when I try to edit the profile (added to the biography) I get an error message

"Error: Invalid data. The following must be corrected:

A marriage date (Peterman-346 married ) cannot be interpreted. Please use YYYY-MM-DD, DD Mon YYYY, or Month DD, YYYY"

And it does not give me the option to "save anyway".

Answer 7

Hi ,

Maybe it has nothing to do with the new validation, but as soon as I added a husband to this profile which was open, it turned yellow. I can't see why because the author left it open. The birth and death dates are completed.

Comments

is the husband marked as living?

---

Nope

https://www.wikitree.com/wiki/Arp-130

---

oh, just realized, died in 1980s, ie within a century, I think they go yellow on principle.

---

Something must have changed at some time, because the profile was open before I connected the open husband. Weird very weird.

Answer 8

I don't think the warning system completely understands about fathers who die during a pregnancy. I got a warning when setting a father's death date as 'After 1834' because his youngest child was born in July 1835.

Comments

Compare Space:DBE_210

---

Hm, that says it checks the gap is not 10 months, but I don't think it is working. If I set the death date of [[Parsons-7861| Joseph Parsons]] to 'after 1834' I get an error, though his son was born before 25 July 1835. 

---

@Deborah 

I guess Project DBE and the datavalidation doesnt have the same rules....

but as Project DBE has matured I guess the data validation in WIkiTree can learn from DBE....  and from an user perspective it would be great if we had the same rules ==> no errors will be found in DBE and also less confusing for the users

Maybe they could use the same help pages/ error numbers ==> less work maintaining... I was part of one update of the help pages and that was a Sisyphus work that Aleš normally our Slovenien hero does by himself....

---

actually, I have found that these error messages don't know the meaning of ''before'' and ''after'', they just take the number literally.

Answer 9

Thanks Chris. I read the following: "

• Square brackets ( [ ] ) -- currently being used to denote modern locations; however, this is not a recommended method. These will be phased out.

If you are currently using parentheses, square brackets or another set of symbols in Location Fields, remove them as you encounter them and use a note in the Biography to describe the information previously contained in the Location Field."

We have literally probably between 8000-10000 profiles with the brackets in the place name field in the {{Dutch Cape Colony}}. I have no issue "phasing" them out, but there has to be an alternative for historical place names. With the "Dutch Cape Colony" we can still just use that (though I have had people complaining that they do not know where it is).

The problem lies with country names such as "Germany" in the centuries before that country even existed as a nation state. This has been mentioned before in quite a few G2G feeds. Even the 'Netherlands" for example was not known as such (the territory also included what is currently Belgium and even some northern parts of what is currently France way back in the 16th century) but as the 'Dutch Republic' until it became a province of France under Napoleon in the early ninetheenth century.

Will there be a possibility (any) of creating and extra field for historical place names, so that we can use the modern day place names so that Google maps can for the most part find that too, or is that currently an technical impossibility ...?

It will also adress the constant automatic changing of place names to modern names (countries, provinces) because most WikiTreers do not know how to disable the automatic place name suggestion, which leads to the situation that after most merges we are back again with place names that did not historically exist. And even we we do, every time a browser (in my case Firefox) is restarted, the automatic place name suggestion is back on again and I have to double click it to an "off" in order for it not to show and created modern day places ....

Comments

I agree with Philip in that location options be provided as historical place names cannot be (really correctly) expressed using currently known locations, and that the semantic web requires data to be contextually correct in order to function as it should. As a matter of interest, can you imagine a country (or area within a country) changing names (e.g. Sudan being a recent case in point), and as such requires all previously created profiles to be updated accordingly? The way the semantic web would preferably deal with this, is to ensure that:

1) coordinates be provided in order for Google etc. to trace the location to its current place, and,

2) for the metadata to reflect which authority file is being used to reflect the data (using URIs as definitive attributes).

I do not agree with providing multiple options for locations (as this goes against the very nature of perfect and reliable information provisioning), but that the location authority list be expanded to include all historical place names, and that this list be a combination of controlled vocabularies (for human interpretation) that feed back into the semantic web (for machine intelligence interpretation – meaning linked data see https://www.diglib.org/groups/linkeddata/).

---

Anybody wanting to use modern names in the location fields should look at Timeline of historical geopolitical changes and contemplate what it would mean for a truly international tree!

---

Hi Wynand,

WikiTree is using the FamilySearch API for place names. Maybe it might be worthwile to contact them about adapting it as you indicated.

---

I agree the automatic gizmo is a pain, in Quebecois project we are having to manually go and correct place names on all the profiles.  The familySearch place name thing is borrowed from them as far as I know, and we can't change or alter it.  Maybe Ales and other like-minded tech guys would like to create our own to fit our requirements?  At the very least, quit with the need to double-click to turn it off, one click is quite sufficient.  And the yellow po-up box should disappear after flashing on right smartly also.