Find a Grave errors

Question

I went from 0 errors to hundreds,  all are find a grave error, and are drawing folks to these profiles to fix a problem that does not exist.

I am getting bad link errors, but they not. Example

* Find A Grave [[http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=123655424 Memorial# 123655424]] Created by: Rex P. Hatfield

getting different death date, which is OK one date is grave stone date one is death cert date.

My profile has a no grave yet error, because I am not dead yet, but I am a member, and I have a link to my page.

I also reference a parent or child grave for info about there child or parent, so names may not match for the bot.

the error routine may need some tweaking.

Thanks

Comments

@Linda I checked the db error list starting with you and the first error I found in Generation 4. I agree with the database Error report that this is an error and the FindAGrave link has nothing to do on the profile it just adds confusion...

What was reported in Generation 4:
572 FindAGrave - Link without matching Grave  

Butler-9079 has a link to Find A Grave Memorial# 123655424 

WikiTree name Amelia Robbons "Milla" Sibley formerly Butler

Find A Grave name Melea Robbins Butler Slater

WikiTree born  6 Jan 1826 in Appelton, Knox, Maine, USA
WikiTree died  4 Sep 1855 in Washington, Knox, Maine, USA

Find A Grave born Dec. 10, 1825 Thomaston Knox County Maine, USA
Find a Grave dead Apr. 3, 1895 Washington Knox County Maine, USA

My Conclusion
WikiTree Butler-9079 is not the same profile as Find A Grave Memorial# 123655424 

As a reader at the first check I feel the WikiTree profile has nothing to do with the FindAGrave memorial that is linked and the link should be deleted. Or any other reader who can explain?

EDIT: Looks like Butler-9853 is the WIkiTree profile that is the same as Memorial# 123655424 this WikiTree profile also have the same FindAGrave memorial feels like someone just copied everything from one daughter to the next daughter ....  the error report on profile Butler-9853 reports no problem on the profile see link

---

Same with next error also an error 572 FindAGrave - Link without matching Grave  

WikiTree Burrows-1301 has link to Find A Grave Memorial# 71577567

WikiTree name Len Thomas Burrows
Find A Grave name George Tillman Burroughs

WikiTree Birth 18 May 1854 in TN
WikiTree Dead 17 Feb 1906 in Trousdale, TN

FindAGrave Birth May 22, 1886 Hartsville Trousdale County Tennessee, USA
FindAGrave Dead Mar. 9, 1959 Gulfport Pinellas County Florida, USA

My Conclusion error correct
WikiTree Burrows-1301 is not the same profile as Find A Grave Memorial# 71577567 and should not be on the profile

---

Examples like this make me even more convinced that more tests are needed and that doing a solution like Aleš has done is the only way forward. Its impossible to find errors like this. Profile Butler-9079 has been accessed 165 times and noone has seen it before....

• More running quality check tests at Wikitree like this makes WikiTree genealogy much better... and will make a difference compared to other online family trees.... 
  
  Over at Wikidata land they speak all the time about how to measure quality and connect more sources like WikiTree/FindAGrave/etc...
  
  They have formulated it as
  
   
  And defined a quality process as 
  
  
  Big pic
  
  Changes done at Find A Grave Also what happen if people start change name/dates at FindAGrave don't we want to get a warning?
  
  Changes of dates/names inside Wikitree It also protect WikiTree from odd changes- If someone change in WikiTree the error report will find that we have a difference with FindAgrave that we didn't have before...
  
  Raise the number of references ==> better quality

---

I have been sending edits to Find A Grave and the following is a copy of one of the many responses I have received from them.

Collaborating outside the box seems to work very well.

Greetings,

This is an automated email letting you know that your recent edit for the William John Ely (1831 - 1909) Find A Grave memorial has been accepted.
Link to updated memorial:
http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=59753945

Thanks for your input,
Find A Grave
http://www.findagrave.com

 

Greetings,

This is an automated email letting you know that your recent edit for the Elihu Cox (1821 - 1883) Find A Grave memorial has been accepted.
Link to updated memorial:
http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=157256476

Thanks for your input,
Find A Grave
http://www.findagrave.com

---

I received some that said that the edit was declined (even though I presented sources) because their data was correct. Sometimes they cooperate, sometimes not. I submit edits often, and most people do accept and edit the memorials. Just be prepared for an occasional FAG memorial manager with a chip on his/her shoulder!

---

It is good that you try. It's always worth a shot and doesn't take much time at all.

Thanks for trying!

---

In Sweden Findagrave is nearly absent so we need to define the cemeteries etc. so it will take until its useful for us, but I think FindAGrave is excellent

• using the Iphone app and walk the cemetery and read about the people.
• easy add the plot name and the GPS position of a grave
  • easiest done using the Iphone app  
• easy take a picture with the app and upload it directly
• for people on WIkipedia you can easy find if we have a matching WikiTree profile
  • map with birth, death and grave locations for profiles on WIkipedia with both FindAGrave and WIkiTree profiles - today 8404 people
• easy to request pictures of a grave far away see Space:Request_A_Picture_at_FAG and are you lucky you get in touch with someone that knows more about the cemetery or the region

I have started to add the following text at FindAGrave to generate traffic to WikiTree 

• Also document at WikiTree profile xxxx

see 

• Petrovic-32
• Sjöstrand-29
• Sälgö-2

---

Excellent point. Never thought about using my phone to do that. What an added value to both sites.

Thanks for sharing!

---

I have been adding links to WT profiles at FAG, too, using html markup for links in the bio. I am unsure how these will carry over when Findagrave transitions to their new site.

Answer 1

My only Find a Grave errors have been on memorials that have been merged with a duplicate so the link doesn't produce a result. I agree with you though you should be able use any memorial as a source to support parents, siblings or spouses.

Comments

Today a whole group of FindAGrave errors was added. You have some new ones.

---

Thanks for the heads up Ales. I guess I have a different prospective than some...I love these little mysteries and working on solving them. I may be one of the people that irritates others in that when I run out of my own errors no one else is safe because I will start working on theirs. Guess I will be busy on my own for a while though.

---

Sorry Ales my love is waning on this new error report. Too many rules that result in errors. Why cant I include the Find a Grave memorial of a spouse on a profile?

Answer 2

I am matching FAG memorial on few conditions. I check dates, and names they must match. Dates are more important then names, but also names must partially match. If you want to know the details of a condition, I can provide them.

In your case, it wasn't matched, because death date was 40 years off, so there must be some error. On a gravestone it looks 1895 and you have 1855.

Comments

Yes its a good tool, but on the others,   Link without matching Grave happens to be a serious error, that I want to fix, but is it the double [[ causing me the error with FAG not found?. I hope not because there could be 1000's and it does not stop the link from working.

---

No.

It is matching of dates and names that gives a mismatch. If you have problem with specific error, give me the profile ID and I will check. It is a new error and there might be some bug.

---

I have "errors" listed that say "572 FindAGrave - Link without matching Grave ."  But when I click on the link in the profile, it goes straight to the FAG memorial.  

Lambert-2011

Holmes - 6477

Bandy-400

Royal-427

Hines-1176

Bandy-348

Enloe-18

Bandy-332

Dygert-89

 

---

But as we all know, much of Findagrave is poorly sourced at best. There is no reason to match our data to theirs.

If our links don't work, that is a legitimate error. Date and spelling discrepancies are not.

As well meaning and appreciated as your errors project is, Aleš, these types of non-errors are intruding on our basic work; in some cases, they are too confusing to understand, let alone "correct."

---

Lindy, we not trying to match our data to theirs. That's backwards (and not the intent of the Error Report). if we are going to use Findagrave references as a source, then there should either be no discrepancies, or:

• explain why we're not using their data (yet still referencing their source)
• or don't reference Findagrave as a source, at all.

---

Nan, I looked briefly at a couple of your profiles, and I believe that there is a bug in Ales' code that is otherwise causing these "false errors".

There is so much unnecessary gobblity gook in those URL links that I suspect his code is having a difficult time trying to determine what the valid URL should be.

For example:

this
http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GSln=Bandy&GSbyrel=all&GSdyrel=all&GSst=45&GScnty=2464&GScntry=4&GSob=n&GRid=34778737&df=all&

could be reduced to this
http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=34778737

(not that the point of the error was to reduce the URL)

---

And most of them are  that shorter format.  So that doesn't explain the "error" report picking them up.

---

I didn't look at all of them... so, I agree, no obvious explanation yet

still could be a parsing bug in his code :(

---

If we are not trying to match our data to theirs (or their data to ours), then there should be no error report for data discrepancies.

Are we eventually going to have to explain every single bit of data that is linked to outside sources (and all our sources are outside sources since WikiTree is not a repository of source documents)?

Are we going to have to explain that the source contains errors, that a transcriber made a mistake, that the other site made a linking error or is revamping its database, etc.?

Are we now expected to complete each profile we create, adopt, or work on before we move to the next profile? Where does this insanity end (okay, that's hyperbole!)?

---

I looked at your profiles and:

I did successfully retrieved the grave number from the biography. You can see it in the Info column.

Lambert-2011 Not matched due to privacy. I don't see the need for private profile, if it is linked to FAG, where dates are exact.

Holmes - 6477 It is the husband's memorial. Try to find the wife's one. She is on the picture.

Bandy-400 It is her sister's memorial. She has her own.https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=33433516

Royal-427 Not entirely sure it is his memorial. It might be, but there is different name, birth date and 20 years difference in death date.

Hines-1176 Her sister's grave. And there are 2 numbers 142414303 and 14214303 One as a text and one in link.

Bandy-348 Difference in birth date and missing death date is too much difference to match it.

Enloe-18 small difference in birth date and big difference in name resulted in a nonmatch.

Bandy-332 dates are OK, but both first names are different.

Dygert-89 dates are OK, but both first names are different.

First names are quite important when linking, since there are often also links to parents or siblings. So if first name is not very similar I don't link it. If you don't see the need to add other spelling of first name as nickname, you should mark it as false error. I could reduce similarity need a bit more but that would increase false errors count on other errors. 

By reviewing your errors I might allow even less similarity in names if both dates are exact match. That would reduce your error count by 2.

I added the comments also in error status, so you know.

---

I'm not opening the profiles of people with living children. Period. If the program can't recognize private profiles, it certainly shouldn't be marking them as "without matching grave."
And again, NONE of these are missing graves. Hines-1176 is NOT her sister's grave, it is hers.  I know a little more about this family than your error program.  And differences in spelling do NOT mean the grave is missing.

Telling us that differences from FAG are "errors" isn't much better than saying that differences from unsourced familysearch trees are "errors."  This is going to cause nothing but trouble.  And it's going to set back the cause of getting more green profiles opened up, because people are going to leave them green to protect them from members who want to "fix" these false errors.

Answer 3

I'm sorry, but I am not understanding the purpose of the slough of Find A Grave errors. I have an exact death date or birth date in the profile based on a death certificate, birth certificate or other date precise source. Find A Grave only has a year based on tombstone (maybe). But  I am getting a "different date on Find A Grave" error. In order to keep my errors list pruned I have to go through the list and mark each one of them as a false error?  I'm a big supporter of the errors project, but I question the value of spending my time doing this. I understand finding internal Wikitree errors (huzzah!), but there must be an almost infinite number of differences between the information on Wikitree and some other external source. What's so special about Find A Grave?

PS - And now that I'm looking at the error list more closely, there are many more errors based on differences between Find A Grave and the profile that just don't merit attention in my view, but now clog up the error report of Wikitree errors that really do deserve attention, from typos to "dirty" post-merge profiles, etc. Is there any way to opt out of Find A Grave errors?

Comments

I meant the inconsistencies between WikiTree and Find A Grave information.

I generally don't include Find A Grave as a source unless there is no better source, and even then maybe not. Just this lunch hour I was struggling with whether to create profiles for children of a profile subject where the only dates I have found so far are a Find A Grave memorial with no tombstone photo or sourcing. I didn't create them.

I generally include a Find A Grave link not as a source but as a courtesy (So and So's Find A Grave Memorial is here), particularly if the link was there when I took over a profile (I have been taking over orphans showing up on my error report). Sort of a virtual trip to the cemetery or a tip off that someone can find an obituary or portrait of the profile subject there. It is these references that were clogging up the error report when I logged in this AM. I agree, that if using Find A Grave for a source, the inconsistencies should be addressed.

In any event, my particular problem was solved - Magnus demonstrated how to create a customized list. I am still not sure that I would have chosen Find A Grave as the first outside source to test against Wikitree profiles for accuracy given that in my opinion it includes a bunch of unsourced information, with a not insignificant amount of junk. But I defer to the drivers of the error project,  which is on the whole a huge positive.

---

I generally don't include Find A Grave as a source unless there is no better source, and even then maybe not. 

If you or any other people are interested in visiting a grave then FindAgrave with GPS information and plot information is a much much better documentation than WikiTree

Eg. Radoman-3 is 

• FindAGraveID 170471422
  • Plot 27 Number 27
  • GPS 44.80889, 20.48572 

Plus you have an easy process to request picture of a grave see Space:Request_A_Picture_at_FAG 

---

Ellen,

Wikidata was the first external source i validated against. 32000 profiles are linked with wikidata.

FindAGrave was the second, with 500000 profiles linked to it.

Now I am deciding for the next one. At the moment I have Family search or DAR in my mind. You can suggest others.

---

So, now I have over 500 errors because Find a Grave uses NO Standard for dates, no requirements for sources and my well sourced profile doesn't match Find a Grave.....FInd a Grave is wrong, not my profiles.

I would rather spend my time finding good sources than marking false error on 100s of errors.....

---

Robin,

First of all, you have 210 errors, not 500. At least report for your managed profiles says so. http://wikitree.sdms.si/function/WTWebUser/errors.htm?UserID=5472076

You sound very confident you made no typos. Did you look at first 20 errors, so you can claim they are all wrong.

This one looks a duplicate to me.

http://wikitree.sdms.si/function/WTStatus/Status.htm?ErrID=585&UserID1=1681266&UserID2=15498916

Other I can't evaluate where the error is. If it is not on WikiTree, just mark them as false errors.

---

Completely agree, Robin.  This "errors" project is getting completely out of hand.  With hundreds of thousands of unsourced profiles (and those are just the ones marked!), we're supposed to spend time on the fact that findagrave has an (unsourced!) place of birth or death, while the wikitree profile doesn't have one?

---

Thanks, Nan, for your support, it really doesn't matter how many there are, the question is whether it is worthwhile to spend the time on them, and I guess that becomes a personal decision.

---

My vote is for FamilySearch. Their database is huge, relatively publicly accessible, and it is desperately in need of assistance with their error correction efforts. They need help in particular with the problem of duplicate profiles starting from the recent generations and moving towards distant generations; they basically can't fix the thousand+ duplicates of Charlemagne until all the descendants have been merged to uniqueness. Same goes for a lot of famous or notorious families.

---

When I have contacted Familysearch about errors, they really do not want to know.

---

Still is important that the errors are corrected if they are not to be repeatedly re-proliferated back to Wikitree. Some Wikitree volunteers will go about fixing the errors whether the FamilySearch staff or FamilySearch users have any interest in it at all.

Error correction to FamilySearch's database also will make it easier to find new links on the FamilySearch and new sources such as birth records, census, marriage records, and death records.

In short, there is utility in selecting FamilySearch for validation processes.

Answer 4

Maybe a  minority opinion, but I'm very happy with this last round of Findagrave.com errors. I have several dozen on profiles I manage, but reviewing them is producing some good data. I have quite a few profiles that are just spouses, siblings' spouses, ones I haven't really paid a lot of attention to. The findagrave errors are giving me a pile of new dates to go and source (not using findagrave, but the vital records & primary sources). And it's giving me a chance to compare my data against findagrave where there are discrepancies. When mine is right and I have a primary source (or a better source than FAG), I just use the "false error" choice to remove it.

It's working for me!

Comments

Glad to hear that.

Answer 5

The new Find A Grave errors are absolutely aggravating.  I just spent a hour going through a number of the new errors, 9 out of 10 are errors on Find A Grave.

If Find A Grave was a primary source (i.e. pictures of grave stones), this would be great.  But FAG is a secondary source filled with the same junk as ancestry.com trees.  I do not want to be put in the position of correcting all the junk on FAG.  It was sort of a goal to clean my error report to 10 generations - this was well over 20,000 corrections cleaning up everyone else's Gedcom errors.  I now consider it impossible to do as the amount of research required to fix what are often FAG typos is prohibitive.  After spending the last 11 months working on db_errors I am finding my enthusiasm tempered - I am wasting my time.

Given the vast amount of un-sourced data on Find A Grave, and given the majority of dates and place names do not come from gravestones but from personal (inaccurate) trees.  We should not be comparing the actual data in wikitree to the data in FAG and expecting them to match.

Comments

I agree with you entirely.  When I have a definite date from a Death Certificate and FAG has just a year from the gravestone, it is a waste of my time to check it out.  There are "errors" I will probably not work on.

---

@Joe Cochoit why are you killing the messenger?

Dont you have a genealogy problem with a profile like Fry-3711 that you have created in WikiTree? 

Why should I as a reader trust your dates in WikiTree instead of the dates added by user Calcat at FAG?

• You say died 1 Jan 1963 but nothing about if it's uncertain or exact
  
  You have just two sources on this profile to prove the facts 
  • Source nr 1 :  1930 United States Census. Database with images
    • Contains no information about the death date
  • Source nr 2
    • Find A Grave reference GRid=175524665 added 2017 mar 4  by you
      • Says death date 7 mar 1963

For me as an reader I would feel it is logical that as you use Find A Grave as a source with an link to Find A Grave with no comments that Find A Grave is more correct.....  But as you say primary sources are the best and neither Find A Grave or WikiTree has any primary sources.

FYI I requested a photo of the grave see video

---

You are certainly correct about the Parl Fry profile.  I can’t really believe I put a date like 1 January 1963 on the profile (I must have copy-pasted without giving it any thought). The fact that the “lack of sources” tag is still on the profile means I put no real work into finding sources and fixing the profile yet – it is on the To Do list.

But I would say look at the other errors on the report you linked.  FAG says Parl Fry was born in Siam, Taylor County, Indiana – this is wrong as he was born in Polk, Taylor County, Indiana as proven by his birth certificate.

The gravestone of Angela Cochoit actually says she was born in 1872 – this is wrong, she was born 8 March 1871.

FAG says Hortense Cochoit was born in 1827 – this is wrong, she was born 11 July 1826.

FAG says Hippolite Manier was born 14 July 1809 – this is wrong, he was born 16 July 1809.

FAG says Hippolite Manier was born in Deuxville, France – this is wrong, all we know is he was born in France, possibly in Foug, Meurthe-et-Moselle, Lorraine, France.

Db_errors is reporting the error FindAGrave - Link without matching Grave for Clair Freiburger – this is wrong, the link works perfectly.

So, 1 out of 6 errors was correct and useful.  I had to re-research every profile to figure this out.  The one that was correct, almost certainly did not actually use the grave as the source of information, but derived from other sources (i.e. his death certificate on ancestry.com).

 

The problem with these new errors is the False Error rate, and the amount of time it takes to figure this out.  The majority of the errors currently presented by the Database Error report has a very high ratio of True Errors to False Errors.  Nearly 100% of the dating errors are in fact True Errors.  Well over 95% of the gender errors were in fact True Errors.  Over 99% of the spelling errors are True Errors.   Over 99% of the relationship errors are True Errors.

The new FAG errors reverse this so that there are more False Errors than True Errors.  I’ll say it again: Given the vast amount of un-sourced data on Find A Grave, and given the majority of dates and place names do not come from gravestones but from personal (inaccurate) trees.  We should not be comparing the actual data in wikitree to the data in FAG and expecting them to match.  It is going to take an enormous effort to check all of these errors, and it is just not worth it when so many errors are turning out to be false.

---

>> The problem with these new errors is the False Error rate, and the amount of time it takes to figure this out.

But genealogy takes time. Fixing db errors like wrong important characters or messed up GEDCOM imports is not genealogy its just a mess you get for free...

Internet and crowdsourced genealogy ==> a mess

I had the same problem today with a profile with 4 different birth dates. See link how I tried to at least explain why I selected the birth date I used in the Wikitree profile. 

Best would be if people inside WikiTree started to help each other to review profiles to find if its good researched and documented.  

---

: Jo Gill edited the Biography for Unknown (Allen) Jones. (deleted incorrect FAG memorial.) [Thank Jo for this]

That was the correct source for the information presented. NO it was not the person it was information in the bio that was being sourced. I was afraid this was going to happen some folks are just too Zealous to "fix" things with out looking.

 

---

If everybody would examine the errors that the report generates like Magnus does when he comments back to us it would be great. But they don't many do like the above and just deletes it Yes the error goes away, but info and sources can be lost.  Don't know how stop that.

---

Joe, I think part of the problem is that you have worked so hard to cure your db_errors and now this crop of non-errors have cropped up defeating your goal!  Totally understandable how frustrating this is!  I trust Ales and Magnus will find a way to make this easier or better.  Otherwise, you might just ignore the FAG errors as being not worth your time to correct.  There is a problem with other people coming in and deleting family members' FAG memorials from a profile when they are there for a specific purpose.  I know I have linked family members' memorials to a different profile, but I linked them to information that I couldn't get any other way at this point in my research.  There might be some discussion about not deleting this kind of info without careful consideration and communication with the PM.

---

@Edie Just to correct

Aleš is the hero of doing all those cool things. I am not in the loop with either WIkiTree+ or WIkiTree.... I was a little bit involved of getting WikiTree inside Wikidata/Wikipedia

If you asked me WikiTree should 

1. Either continue as before with no error checking/correcting and a big chunk of unstructured text that is hopefully good reading (GEDCOM import is not) ==> people get less upset
   
   or
    
2. Use the power Aleš is adding and start working with better ways of expressing a profile like
   1. this link is to a FindAGrave that is not the same as the FindAgrave profile
   2. this person is buried on the plot at GPS location xxx that is the same as FindAGrave Memorial xxx and the data should match because its the same person   
   3. Start adding quality checks like peer to peer reviews and some measurement how good a profile is 
      
      ==> better genealogy quality and more collaboration... but also more frustration
      
      ==> WikiTree will be special in the landscape of crowd sourced genealogy but many people will disagree and not like it....  doing genealogy and do research is not for everyone some people like more genealogy "light"

 

---

I always appreciate your input, Magnus. I'm aware you're not part of Wikitree admin, but I think you have great suggestions.

Answer 6

I got feedback on my Request of a Picture at FAG - link my requests they have now been at  Fort Wayne Library to look after more information

• FindAGrave  Parl L. Fry, Greenlawn Memorial 175524665
  • connected with WikiTree Fry-3711

See my FindAGrave page

]

Parl L. Fry, Greenlawn Memorial The cemetery will not tell me where someone is buried so I do take the time to walk the blocks over a period of time. If they do not have a tombstone, I will not find them. Needless to say, so far I have not come across his stone. I was at the Fort Wayne Library and did look up his obit which was in the Journal Gazette on March 8, 1963. Would you like a copy of it. Added by Barbara Wolf on May 03, 2017 7:46 PM

Comments

Wonderful response! Definitely worth the effort. I've sent probably 20 error corrections to FAG and am getting them back daily. Most are changed to the dates that I've supplied, one or two disagreeing, but supplying a reason.

---

I received from Barbara Wolf more documents but this looks like a good hint that the death date was Mar 7 1963 for  

• FindAGrave  Parl L. Fry, Greenlawn Memorial 175524665
  same as 
• WikiTree Fry-3711

• The Fort Wayne Journal Gazette (Fort Wayne, Indiana) Ancestry

• Wikipedia:The_Journal_Gazette