Database Error and the FAG error Friend or Foe? I think a great tool to avoid Vandalism

Question

I read of all the upset comments about all the mismatch found in profiles with Find A Grave links

BUT this is a double edged sword

1. If we just links the correct Find A Grave profile(s) from WikiTree
   
   THEN 
    
2. If we get some vandalism in WikiTree on dates/names we have bigger chance to find it next time the Database Error project checks the profile with Find A Grave and will alert us on a difference

More external references that are checked ==> better quality 

Answer 1

You may well be right.

But it is still very inconsiderate and respectless to implement this type of discrepancy checking before separating it from the error checking that is included in the dropdown menu on every profile.

Comments

Dont follow your thoughts Eva
>> inconsiderate and respectless 

If you check the two errors I investigated that I guess was the result of some bad copy/pasting see G2G link for me this is error checking when it starts adding genealogy value.

In the mentioned case someone has added a source and made a mistake. No one has found this before this check is done... 

I feel the respectless act is done by the person adding this wrong data to a profile without checking or explaining why its added (if its not a mistake)... adding things like this is some kind of genealogy vandalism.... and just add confusion to the reader... 

The Database Error tool is just a messenger ;-)

---

I have to agree with Magnus here.  Those two examples he cited were so radically different - yes, they were ERRORS.  It worries me slightly that there are so many of these type of mistakes by people who call themselves genealogists.

---

@Ros
The good thing is if we can have a learning process in parallel also inside WIkiTree. 

I got some feedback today from Eva that I focused on some odd facts to much..... and its so easy when doing genealogy that you miss the focus and start digging to deep at one place. Doing genealogy takes time and is a learning process.... 

I love the Grand Ma genes yesterday at 42 minutes about how to write interesting Wikitree profiles by Bobbie Christmas. Its so much to learn about genealogy and it takes time to master. 
 

'I feel collaboration is the key and learn from each other and Project database is a friend we should be more than happy for that Aleš has let us use...

>>  It worries me slightly that there are so many of these type of mistakes by people who call themselves genealogists.

And that is also the beauty with a common open tree as WikiTree. You just need one person that start pasting FindAGrave links on every profile without understanding what he/she does....

I really think its sad that we inside WIkiTree don't agree how a good citation looks like for FindAGrave, I think if we started to use the Template:FindAGrave with the name in the Citation more people would start seeing that they do something odd... hopefully this project database error gets us focus on how to cite FAG

• {{FindAGrave|69423684|~~~~|Napoleon Bonaparte}}
  • Memorial ID 69423684
  • ~~~~ to get a timestamp
  • Napoleon Bonaparte to get the name of the Find Grave profile in the citation

 

Answer 2

This assumes that the Find A Grave profile is correct and sourced. The error check is not run against the tombstone photo (the only somewhat primary source on Find A Grave), but the memorial, which frequently is no better genealogy than the frequently maligned Ancestry Family Trees. What is the value in an error detection tool that results in the following:

575 FindAGrave - Different birth date 

From the profile that was tagged with the error:

Anna Valentine was born 27 July 1873 in Wayne County, Iowa. ^[1] Anna Valentine died on 22 October 1951 in Osceola, Clarke, Iowa. She is buried in Maple Hill Cemetery in Osceola. ^[2] Her Find A Grave memorial is here.

Explanatory footnotes:

1. ↑ July 1873 is stated in the 1900 United States Census. Her death certificate states a birth date of 27 July 1872, as does her tombstone, which would be one month after the reported date of her parent's marriage. Censuses through the 1910 United States census give a birth place of Iowa; later censuses state a birth place of Canada, as does Anna's death certificate.

The death certificate is cited at footnote two.

The example I cited above is the first Find A Grave error in my list. The next one cites inconsistent birth date. I have a source for 1901, a birth record. Not cited in the profile then, but now it is, but whether it was or not wouldn't have made a difference to the error report. Find A Grave is an empty memorial - no tombstone photo, no source, nothing but a notation of a birth year of 1900. It's an inconsistency between two online sites, but it is not an error, and the Wikitree profile has a source. The third Find A Grave error in my list also cites inconsistent death information. I cite a death year based on when the subject was recorded as dropped from the Civil War Widow's pension roles due to death. The Find A Grave memorial cites a specific death date, unsourced. Same year as I have. Again, an inconsistency between two online sites, but not an error and the profile has a source.

Comments

I agree with Ellen. Many of the errors in my error list are this way. I flat out refuse to amend my WT profiles unless I can find a source, which is not presented at all on FindAGrave. (I know a family member on FAG who has created many memorials lacking any sources; only went on word of mouth.) The birth dates are calculated from the tombstone inscription of x years, y months, z days. (We know how inaccurate that can be.) So, I can go through the error report and click the dropbox and explain why it was not corrected. It's all I can do.

---

>> It's all I can do.

You can request documents from the cemetery to hopefully learn more see Space:Request_A_Picture_at_FAG#Administrative_documents

Answer 3

I, for one, don't feel it is our responsibility as WikiTree genealogists to explain every little data discrepancy that is caused by differences in the sources we use to create our ancestors' profiles.

Therefore, I will now be adding a Research Note to the profiles I manage to let viewers know that the sources may contain discrepancies, as well as potential causes of the discrepancies.

For any of my fellow managers who are interested in doing the same, here is the text of my note:

:'''Viewer Tip'''
::Sources may differ on the information they provide. Causes include language barriers, lack of information, incomplete information, incorrect original information, transcription errors, conflation, confusion, and purposeful misinformation. Viewer should consider all information and sources suspect.
:  ~~~~

Feel free to copy the text as is or reword it to your own tastes!

For those who aren't aware, the four tildes (~~~~) will put a timestamp on the text; I suggest leaving them on the separate line if you use them.

Enjoy!!

Answer 4

Since I am extremely familiar with my local cemetery of over 4,000 burials, I will tell you about three common situations which occur in Find-a-grave.

1)  Cemetery records list a Patricia Flynn, female, who died in 1912.  I pull her obituary, and it's Patrick Flynn, male.  All of his relatives have him dying in the wrong city in the wrong year. *Cemetery records are wrong.*

2)  My grandfather was born before his father died in 1892.  He was probably born in 1891 (I have two sources for his birth that substantiate that).  His tombstone says he was born in 1892, because he really had no idea, so my grandmother used that year.  *His tombstone is wrong.* (and if he had a death certificate, it would presumably be wrong too, but no one issued one for him).

3)  Our city bought a cemetery management program that requires you to enter a birth month and year and death month and year, even if one wasn't recorded in the original records.  Approximately 1/6 of everyone in the records is randomly assigned to being born on the first day of January.  Unless I can find independent confirmation for their birth date, I leave that out of Find-a-grave, but others add that in as though it's a legitimate date.  Find-a-grave is wrong because the city record is wrong.  By using this ridiculous software, the city has created even more errors in the records.

4)  Lots of Find-a-grave entries use a burial date instead of the actual date of death.  Sometimes they let you know about that; frequently they don't.

If I have evidence, I submit corrections to Find-a-grave, but that doesn't mean they'll ever be changed or updated.  Find-a-grave is a tool that can lead one to good research, and it can be especially useful at illuminating possible family connections, but overall, since it is user-created and there's no ability to add sources, it isn't an extremely reliable source. So why bother checking for discrepancies between Find-a-grave and Wikitree?  If I've researched someone, added sources, and noted discrepancies in the biography, then why should I worry about discrepancies between Find-a-grave and my Wikitree profiles showing up in error reports?  Life is too short.  I'm glad that you found actual errors using the data checking, but I looked at my 11 errors, and none of them were actual errors. Either I have evidence that contradicts Find-a-grave or I am still working to resolve discrepancies between our dates.

Comments

I have been adding sources, at least by name, in the bio section on FAG recently. I even insert links to records, indexes, etc. Now, they can't be extensive, but it can be done. I've seen people insert line after line of census docs, which I think is overkill.

For example: https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GSmcid=47463070&GRid=143830033&

and

https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GSob=c&GSsr=41&GSmcid=47463070&GRid=83947111&

What I don't know is if those links will stick when FAG goes to their new format.

---

>> FAG goes to their new format.

please explain?!?! EDIT found this link

Best practise when linking in a wiki is to use a Template ==> if the WEB URL change you can hopefully just change the Template and not the 400 000 links

You have Template:FindAGrave  ==>
{{FindAGrave|143830033|~~~~~|John M Acela}}

will create a link with a timestamp when accessed the FindAgrave memorial and the name used at Findagrave

{{FindAgrave|83947111|~~~~~|Julia Ann Bowman Andress}}

---

Good written  J. Crook

I guess we will see new challenges with crowdsourced genealogy and "open" profiles.... 

What I have learned is that the administrative documents of a grave could be useful to have. 

I would like to see some kind of standard template how to describe a cemetery in WikiTree to help other people doing genealogy at that cemetery. Like

1. Location
2. Link FindAGrave
3. Who to contact to get administrative documents
4. website
5. WikiTree page 
6. LInk to a map over the cemetery

See category for a cemetery in Stockholm I did

>> why should I worry about discrepancies between Find-a-grave and my Wikitree profiles 

Why have a link to a bad source? With other data than you have on the profile? 

---

Magnus, I use that template on WT, but there is no template to use on Findagrave. There are only "guidelines" as to what is acceptable, and most of the concern is over who can manage a profile and when transfers of management are required. FindAGrave is reformatting their web site, so I'm not sure if the links I have inserted in FindAGrave memorials will work any longer. That is what I was getting at.

---

Why have a link to a bad source? With other data than you have on the profile? 

In some situations, the findagrave contributor, probably a volunteer genealogist like me, appears to have information I don't have access to.

Or, they have the same information, but their interpretation differs from mine, and they apparently have a reasonable basis for that interpretation.

In either of those cases, our data may not match but that doesn't mean that theirs, or mine, is "bad".  A user of WikiTree should be encouraged to have a look at both profiles and reach their own conclusion.  And, in a best case scenario, contribute what they know to resolving the discrepancy.

Answer 5

Example today of vandalism and the good thing of having projects like Database Error checking things and more links other sites...

1. In Wikidata we a attribute P2949 and nearly every a bot is run that checks the related Wikidata profiles in Wikipedia that they are set up ok ses change list and Wikidata:Database_reports/Constraint_violations/P2949 
    
2. Today I got in my watchlist that the report has changed
3. We had a violation on profile El Cid (Q43958) that is WikiTree Vivar-3

   that he was changed to be an animal (Q729)

4. When I checked El Cid  we can see

   1. 2017-04-11T11:47:00‎ 190.160.85.207 (talk)‎ . . (54,019 bytes) (+4)‎ . . (‎Changed claim: instance of (P31): animal (Q729))

   2.  2017-04-11T20:48:09‎ ‎ m . . (54,015 bytes) (-4)‎ . . (Reverted edits by 190.160.85.207 (talk) to last revision by KrBot)

And if the bot hasnt seen the change I would have

 

I guess if WIkiTree will open up more profiles we will see more vandalism and need more tools like Project Database Error that check the data and also links to other sites...

Answer 6

Just so you know, I co-manage a profile from the Euro Aristo project which includes links to Wikidata and Find A Grave. Wikidata and Find A Grave give different birth dates for this person. So whatever I do, I get an error (unless someone gets Find A Grave to be fixed - I think in this instance, Wikidata is more likely to be right than F-A-G).

Here it is: https://www.wikitree.com/wiki/Wittelsbach-140

It is NOT an exemplary profile; it is a work in progress, in fact, most profiles are. And since it is a work in progress, there are - I have - priorities. Fixing such errors as bad characters in names, bad locations, mother too old, wrong gender.... is high priority. Checking against Wikidata or F-A-G is very, very low priority especially when I'm sure of the sources used.

And if we come to checking data in Wikitree against other "genealogy" sites (Ancestry, or why not Geneanet and their numerous conflicting duplicates), then the resulting reports had better be separated from the regular error reports. Just my opinion, of course.

Comments

You can always mark a thing as false error....

My guess is that the best is just to leave a status comment and say more research is needed.....

On this profile you can see the problem today with Wikidata. That birthdate in WikiData Q57989#P569 has as an reference imported from Wikipedia which is a no no. All facts should in the best of all possible worlds be

1. Possible to verify
2. And not part of Wikipedia or Wikidata

The Wikipedia article Charles_I_Louis,_Elector_Palatine has one source The Peerage that at least has some more sources... 

Feels rather weak sourcing but I have no knowledge about genealogy and the peerage of Britain or the royal families of Europe....

---

Yes, I have marked it as False Error with a comment explaining that Wikidata and F-A-G are different.

I'm glad to learn that importing into Wikidata from Wikipedia is a no-no because I've found that it is done all the time... (sometimes Wikipedia has good sources too).

In that particular case, various Wikipedias (and other web sites) give his birth date as 22 December 1617. The Peerage.com has 12 December, Roglo as well (with a poor source). genealogy.euweb.cz and Leo van de Pas have 1 Jan 1618. Theroff has 1 Jan 1617. Some sites honestly say "1617 or 1618". German nobility handbooks might be better, but I don't own any. Guess I'll have to add a Disputed Birth Date section.

---

Its a mess... 

WIkidata tries to address it at least. With people like Aleš it maybe can work

Here you have a real time map of who is editing WIkipedia

Answer 7

Just because it's set in STONE, Doesn't make it right.  As many of us know, Find-A-Grave is just another source which may - or may not be correct. As an example we have https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GSln=parman&GSfn=hily&GSbyrel=all&GSdyrel=all&GSob=n&GRid=14890868&df=all&

who is my 3rd great grandmother. Note that on the headstone it says May 12, 1798 as the date of birth.  Her actual date of birth is 26 March, 1812. Of course the person who created the Find A grave page copied the incorrect date which is often carried over.

In another example from my error report below, the 1893 date is correct.

575 FindAGrave - Different birth date	Parman-58 H	18990301	Carrie C Parman		1893-03-01 Union City, Harrison, Missouri, United States	1927-01-19 Worth, Worth, Missouri, United States	Female		Parman-30
	61340936		Carrie C. Parman		1899-03-01 Missouri, USA	1927-01-19

Comments

Maybe update Space:FindAGrave with this examples

Do you have any administrative records of the grave and what do they say?  I trust things like that more. 

Visited yesterday a Grave in Göteborg Sweden and it was a family grave of Nils J Bildt but in the Administrative record Nils J Bildt is not mentioned 

Nils J Bildt family grave

---

Magnus,  I finally got around to adding the information I mentioned above.  Sorry I could not find any supporting documentation, but the second one is obvious.