The current GEDCOM process allows a living person to be added as a deceased person in FamilySearch F

LegacyUser

Tom Huber said: The following was prepared in another discussion when I ran across the living added as deceased problem with a GEDCOM ingest.

Yet another argument for stopping all GEDCOMs from being ingested into the massive tree:

Some work was done with the add GEDCOM file interface, but it is still in desperate need of being fixed. There is a current flaw that allows living persons to be added as a deceased person in the tree.

Basically, my history produced a number of issues, all dealing with uploading a GEDCOM to Genealogies and then running a compare function against the uploaded file with FamilySearch FamilyTree.

The basic operation:
Step 1 - upload a GEDCOM file after using Search -- Genealogies, and clicking on Submit Tree at the bottom of the page.

Once uploaded, The user is presented with three options: 1) "Compare" as a button, 2) "Download Your Original GEDCOM" presented as an icon, and 3) "Delete GEDCOM" presented as a trash basket icons. The icons are widely used, but the mix of icons and words could confuse computer novices.

Notes:

There is only a singled word that says "Uploaded" on the line with the newly uploaded GEDCOM.

There is no message that states that the user was successful in uploading and contributing their file to the Genealogies system, or a note explaining that eventually, their contributed GEDCOM will be searchable by others.

There is no button or link to leave that page.

There is a rotating display of three steps for adding the contents of a GEDCOM to FamilySearch Family Tree. The tree is not explained or introduced.

The above could be vastly improved to let the user know that they have uploaded and contributed their GEDCOM to the Genealogies section of FamilySearch.

If the user is not aware (they are not told) that they've completed the goal of uploading and contributing their file to Genealogies, they see only the three options. The natural tendency is to follow the rotating instructions that now tells the user to compare their uploaded file with FamilyTree.

So...

Step 2 - The user presses "Compare"

The compare process has been improved since we started really getting into the system a couple of years ago. We found some serious flaws (including, but not limited to missed comparisons, which I found by downloading a portion of one of my ancestral lines and producing a GEDCOM with Ancestral Quest).

The major flaw showed that the process actually could not identify the same record in the tree with the GEDCOM produced (via Ancestral Quest) from that record. This was reported in one of the discussions and eventually, someone woke up to the fact that this was happening and that issue was eventually resolved.

Unfortunately...

If the compare process had already been run, the system did not rerun the process with the new routine. Instead, the old compare routine results were still in place with its inherent problems, including the ease at which GEDCOM persons could be added to the massive tree (as duplicates). This still plagues the system. The old "clunky" code (Ron Tanner's word) was still in use and the flaws were still in place.

Once the compare process is complete (time varies depending upon the size of the uploaded GEDCOM) and indicated with the word READY, the user has three options. Instead of "Compare", the first option is "View" as a button, and then, 2) "Download Your Original GEDCOM" presented as an icon, and 3) "Delete GEDCOM" presented as a trash basket icons. The icons are widely used, but as I noted before, the mix of icons and words could confuse computer novices.

So...

We are back to seeing only three options, the same problems that were noted after uploading the GEDCOM.

Now the user is left with really clicking only on the View button.

Step 3 - The user presses "View"

This is another area that has been vastly improved over the previous systems, but there are still problems that exist.

After the compare problems were finally addressed, the view option presented a menu of options -- Including one to add persons who were not found in the tree. At that point, the compare function was not as thorough as it is now, but the same problem still exists in that once run, the compare function's view function is the same as it was before, so a previously uploaded and compared file would present the same option menu.

The current view does not present an option menu, only a report of what was found by the compare function. This is a vast improvement.

Now, the user has two options: "Review Results" as a "button" and "Cancel" in fine print as an active "link". It would be nice if FamilySearch would be consistent and present both Review Results and Cancel as the same sized "buttons"

Step 4a - The user presses "Cancel" -- This is fine, but it returns to the previous screen with the same three options as reported above. No where is there a "finished" or "done" option. Yes, one can select a main menu item and leave that way, but there is no close option for this process at any point.

Step 4b - The user presses "Review Results"

Up above I mentioned the old results presented a menu of options that were replaced by a report. Now old "menu" is now a "filter" on the Review Results screen. This is, in my opinion, a mistake.

The following screen shots illustration the problem, but note in the past, the filter was not in place and functional:


Because the filter was not in place, if a user wanted to add his GEDCOM to the tree, the user would need to go through the entries, ten at a time. Because this was long and tedious, the number of duplicates that could easily be added dropped to zero.

Joe Martel reported about that time that the duplicate production from GEDCOM files had dropped to be the lowest among all the methods that could be used to add a person to the massive tree. That was understandable.

I don't know when the filter was put into place. I haven't done any further testing until today, so do not know when the change was made.

At this point, one can now select the filter as if it is an option to display only those records in one of the categories. "Living" is meaningless, but is not complete as I will show in the next screen.

Add has 8 records that were not found or classified as "invalid/living".

The problem is that the first record is for a living person.

So this represents new "bug" with the system. Now, if I add this person to the tree, what is going to happen? Is it going to show up as if the person is deceased, or will the person be created in my Private space as a living person?

Never mind that this person should have been classified as a "living person" and not presented with the option to add. Or, at the very least, with a message explaining that the person is living and therefore will be created in the user's private space -- not viewable by any other user.

I decided to "Add" the person to the tree to see what happened.

The person was added, but not as a living person in my private space:

When I saw this had happened, I deleted the person, rather than process the research hints. The problem is that the record, as a deleted record, is still viewable, meaning that the privacy laws have been violated that FamilySearch attempts to adhere to...

That is a major problem! -- I am reporting this as a separate discussion thread so it can be addressed. Note that changing the compare function will not fix the problem with those files that have already had the compare function run!

LegacyUser

Tom Huber said: There was a tongue-in-cheek response to a quick fix in the https://getsatisfaction.com/familysea... discussion thread. That prompted me to be more complete about the process, since it had been a while since I had done any testing with the flawed GEDCOM upload/compare process.

LegacyUser

Tom Huber said: Another of the "Add" persons has no established death date, although there is a find a grave record for the person. The problem is that the gravestone has the person's name inscribed on it, along with the husband (who is dead and has both birth and death dates.

Again, this GEDCOM ingest process allows me to add the person as a "deceased" person, even though there is no evidence they have died.



The rest of the adds are not (as far as my records indicate) in the tree, but I haven't taken the time to check at this point. The GEDCOM I used was created back in January of 2019 !!!

Now to the other problem that continues to plague the system. It doesn't have to do with creating duplicates or deceased person when they are still alive, but with mangling a currently-existing record.

This is a compare process problem and one that could be resolved with a much better display, more along the lines of comparing two duplicate records which is actually what is happening.

In the following shot, note that the only difference is the date and how it is recorded. I have converted to spelling out the month in my records, but now the system thinks that the dates are not the same. Image demonstrates the inconsistency with the way the month is presented. With the birth and death dates, the existing record has the month spelled out. The system suggests that I should replace the existing record. The burial date shows that is not the case because both the existing record and the GEDCOM use a three-letter month that matches.

If I press replace, the screen shifts downward and a reason statement is presented at the top of the details. It is easy to miss in the present design.

Well, at least the option of recording a reason statement is there, even if no explanation is provided.

But...

That reason statement has to cover ALL replacement changes made. It is not tied to the vital item... And that is also a problem.

To say the least, the current system is far from as good as it could be. The compare fails with anything recorded in the death field, including the word "Living" and the comparison of matched records is sadly lacking and needs to be at least as good as the duplicate merge comparison screen.

LegacyUser

Robert Wren said: Nicely analyzed, Tom

Caution - facetious comment posted below (close your eyes, Don't READ):
...
....
........

BUT, Tom, isn't this a GOOD thing? The GEDCOM abuser would then be able to beat everyone to the ordinance phase! Only a couple more clicks would be needed!!

...

...

I'm sorry - - - NOT,

I likely violated the Code again. Woe is me.

LegacyUser

A van Helsdingen said: If living people can be added as deceased, then that is a serious error that has major ramifications for privacy issues.

If FS wants to take privacy seriously and stay within the law, they should probably suspend the GEDCOM import feature until this flaw has been resolved.

If ordinances could be performed for those persons, that would raise questions about freedom of religion etc.

LegacyUser

FamilySearch Moderator said: THanks Tom. Excellent work. The team is now aware. In summary the Gedcom upload had a Living Person that was ultimately injected into FT as a deceased person, which would be an error.

LegacyUser

Tom Huber said: My bottom line to all of this (and echoed by a number of other participants) is for FamilySearch to shut down the ingest via GEDCOM after the GEDCOM has been uploaded to Genealogies.

That shut down should last until a new ingest system can be implemented which will 1) run a completely new compare process
2) not use a previously run compare process, but allow the user to run the new process
3) use the same (but improved) merge comparison screen that is used when a duplicate is discovered. The improvement would allow/require updating the reason statement for every item that was moved to the surviving record. This includes all of the "other" categories and would require reworking the entire sourcing of "other" conclusions and entries.
4) convert GEDCOM dates to the same system used to represent dates in the massive tree so that the dates are not being compared like apples and plums

LegacyUser

Robert Wren said: May I add #5 to your list: (if it is deemed necessary and desirable to allow GEDCOM FILES into the FSTree)

5) Limit all GEDCOM batches which are allowed to be added to the FSTree to 100 names.

LegacyUser

Adrian Bruce said: Tom re EGR and
"this GEDCOM ingest process allows me to add the person as a "deceased" person, even though there is no evidence they have died."

I confess I'm not at all familiar (thank goodness?) with the GEDCOM loading process so it might be that I'm reading this wrong but my initial reaction as a programmer - rather than a user of FindAGrave - would be that there is evidence of their death because there is a statement of their burial. (I understand the reason for the stone looking like that).

It's not clear to me what the software should do with such data. I can think of lots of people who would record a burial from parish registers but omit the date or place of death because it's not in the parish register - I wouldn't, I'd estimate the date of death but others simply won't. So we have to acknowledge the possibility of burial data with no death data.

This particular instance has no burial date but again I'm not certain that I'd take that as evidence that they were still alive - a burial place alone might suggest an undated memorial at that location.

Would it be possible to insert dialog with the user at this point to establish the truth of the death or not? Otherwise it is a knotty problem, I have to say....

LegacyUser

Adrian Bruce said: Re IKP as a living person.

I can't tell but it seems to me that the word "Living" is in either the date of death item or the place of death item. That simply isn't sensible GEDCOM - it's a bit moot if it's invalid - after all, there might be a place called "Living". It's almost certainly not valid GEDCOM for a date, although there is this thing called a date phrase.

So again, while it's clear to any carbon based life form reading the GEDCOM that said person is still alive, it's actually tricky for software to tell that said person is still alive. (Again, I'm searching deep into my memory but I don't think that GEDCOM has a universal way of indicating someone is still alive). (That's not mentioning different languages on the GEDCOM!)

So - like I said - tricky.

LegacyUser

joe martel said: Tom, did you create the Gedcom file? In a certain app?
Is the person there actually declared dead? The word "living" in the DEAT field does not mean they are living. 
Maybe you could post here the Gedcom data for this person. I believe if there is a DEAT field then that person is dead.

LegacyUser

Adrian Bruce said: Joe - I have the same concern as you. However, seeing experience with GEDCOM files from various bits of software, suggests strongly that half the programs around can't be trusted to implement the standard correctly and a bit of defensive programming might be in order, so it might very well make sense to interpret that "Living" as meaning just that - if that use looks at all common. (I may be stating the obvious to anyone who's actually programmed GEDCOM read routines.)

LegacyUser

Tom Huber said: Joe -- Yes, the GEDCOM was created from my local Ancestral Quest database. In the case of Isaac Karl Post (who died in 2018) the "Living" was entered in the date field. It had been a number of years (and AQ upgrades) since I looked at the record and at the present time, AQ protests numerous times when the date field is not standard (Living is certainly not a standard date).

So that one can be considered a "pit error" with the understanding that it still is a problematical entry when it comes to GEDCOM ingesting.

That isn't the case with Eleonora Gay Rassmussen (who is still living as Eleonora G Hindman at the age of 86). There is no DEAT entry in her GEDCOM entry:
0 @I12579@ INDI
1 NAME Eleonora Gay /Rasmussen/
1 SEX F
1 BIRT
2 DATE 1934
2 PLAC Nebraska, United States
1 BURI
2 PLAC Fairview-Rider Cemetery, Rushville, Sheridan, Nebraska, United States

It appears that the system saw the BURI field as populated and interpreted that to mean that the person was deceased.

In this case, there is a listing for the person (without a given name, but with the correct parents) in FamilySearch FamilyTree. There is also a Find a Grave entry for her with an "unknown" for the death date/place.

ZabaSearch turned up a record for her still living.

LegacyUser

Tom Huber said: This gets back to the original argument that the current GEDCOM ingest (into Family Tree) is still lacking. In the past, that was an even bigger problem, but it is still possible to end up producing duplicates (in the case of Eleonor) or adding a person whose GEDCOM record has a mangled DEAT (DATE) field when the person actually may not be deceased.

About the only thing that can be done at this point is to stop the Ingest after the file has been uploaded into Genealogies. My example shows that these two records would create records that should not have been created (added to Family Tree) due to both persons being born within the past 110 years and without ample evidence of death (minimally a date and/or place). The burial record is a logical entry but creates a problem in that in many instances, we may find a headstone without dates but believe the person is buried in that cemetery. The practice of adding a person's name and birth date with no death date on a headstone with a couple is not new. My mother died in 1950 and when my father had her buried, he had himself listed (with birth date but no death date) on their gravestone.

So what can be done?

At this point, aside from the often requested halting the FamilyTree ingest from a GEDCOM file, the system would have to be rewritten (Ron Tanner called the code "old and clunky") and use the merge two records system for adding new records and correcting existing records. That system was recently upgraded and evidently needs some additional work to correct existing problems.

The other problem is that any band aids applied to the existing code would still allow the older compare routines to stand, including this one. That has to be fixed because it allows a person to go back to an old upload that they (then) ran the old compare program (with its inherent flaws) and adversely impact Family Tree. I realize this is a remote issue at this point because I don't know of any cases where an update to Family Tree was made from an older upload and compare. But in cases like this one, not forcing the user to rerun a new compare would still leave the problem exposed.

LegacyUser

Jeff Wiseman said: It's really about consistency. If you have a DATE field in the DEATH attribute, it should contain a DATE or nothing at all! Some third party programs allow you to enter text into a Date field. As a result, you get a GEDCOM that has a Death Date field in it that contains something OTHER THAN a date!

Inconsistencies and sloppy scope control on data types is just asking for someone to come along and try to figure out how to use a data field in some "custom" fashion that uniquely meets that person's needs or workflow (and usually is totally cryptic to everyone else).

That is fine in a private tree and database, but anyplace where resources are being shared (whether it is a public road or a public family history tree), you must have well defined rules for how everyone is to use them and, where necessary, someone to police those rules. Otherwise you get anarchy.

LegacyUser

joe martel said: Thanks Tom. I would venture that having A DEAT or BURI field (maybe there are others in GEDCOM) would be imported into most programs as deceased, regardless of a date or place modifier.

With an optional modifier I don't believe any program could interpret the meaning of the text and reverse the purpose of BURI and DEAT to mean living.

I find it odd that AQ would put "Living" as a value for date.
Am I understanding this correctly? If so the FS Gedcom ingest did what it was told with the DEAT or BURI declaration.

LegacyUser

Jeff Wiseman said: Joe, I think that the AQ thing goes back a long ways. If I remember correctly, you can actually put ANY text into a date field up to 50 characters. However, the system will complain about it not being a "standard format" and will ask again if you are really sure that you want to do it. If you insist, it will put it in for you.

In the "old" days of PAF, when you had an empty death date field, you couldn't tell if it was because there was an unknown death or they were still living, so this was a hack that some used to get around that.

Of course, 150 years from now they will still be shown as living :-)

Again, I personally believe that you shouldn't use date or name fields as a hack for Notes or any other type of encrypted code

LegacyUser

Adrian Bruce said: Yes, it is valid GEDCOM to use what's termed a Date Phrase in a Date item. So one could record that someone died "During WW1". However, the format for a Date Phrase is tightly defined - I have an idea that there has to be quotes around the phrase and I know that it is also possible (though not mandatory???) to include a standard GEDCOM Date value somehow - BET 1914 AND 1919 in the case above.

So I'm pretty certain that just having LIVING in the Death Date is not actually valid GEDCOM. Though note that I'm saying this without double checking the Standard.

But.... We can't point to the GEDCOM manual and Tut, Tut at AQ for allowing LIVING in that item if we don't also play our part - "we" being FS. The GEDCOM load needs to validate the input and that LIVING isn't valid, so should have been rejected, thus leaving the imported profile with no death, ie leaving the profile as living and therefore private.

Defensive coding - do the correct validation! Except, that's easy for me to say, I have no idea how easy it is to reject single GEDCOM tags in an import.

LegacyUser

Tom Huber said: Here is something to think about. When I work with Eleonora Gay Rasmussen from AQ and interface directly with FS, I can add her to FS, but because of the data in the Burial place, the system will add the word "Deceased" to the death field.

This is another problem area and because it involves Ancestral Quest, I'm going to copy this to the AQ team and let them deal with these issues.

It also shows how AQ can ingest a duplicate record when it should not, but part of that goes back to the system already having certain people in the system, including, at this point, Eleonora as a deceased person (even though no evidence is present to support her death.

I'm not sure there is an existing solution. Joe is correct in that

I don't believe any program could interpret the meaning of the text and reverse the purpose of BURI and DEAT to mean living.

This is something that hopefully, the AQ staff will be able to look at and decide how to approach this rather unique situation.

Getting back to the issue itself, as I mentioned above, it will take a new approach to ingesting any duplicate where there is a question about the person being living or dead -- especially when duplicates are combined.

In the meantime, I'm going to fill in the blanks for Eleonora so that she is properly recorded as living.

LegacyUser

Adrian Bruce said: For your info, here are some GEDCOM snippets indicating deceased individuals in a more unusual way:

1 DEAT
2 DATE (Before his wife)
2 NOTE Testing Date Phrase with no Interpretation.

Note the Date Phrase is in brackets, not quotes as I thought.

1 DEAT
2 DATE INT 1914 (During WW1)
2 NOTE Test Date Phrase with INTerpretation

Apparently only single, unqualified dates are allowed - not range, period or approximation.

1 DEAT Y
2 NOTE Test adding Y for Yes.

GEDCOM allows a "Y" suffix on the event line to say "Yes - this has occurred". To quote the manual "The presence of a DATE tag and/or PLACe tag makes the assertion of when and/or where the event took place, and therefore that the event did happen. The absence of both of these tags require a Y(es) value on the parent TAG line to assert that the event happened"

The above 3 are all valid GEDCOM, validly describing deceased individuals.

But what does this mean? Since it doesn't have a DATE, PLACe or "Y" suffix, logically it means that the death has not happened. but that assumes that the software produces correct GEDCOM in the first place!!

1 DEAT
2 NOTE Test no stuff for death other than a Note

LegacyUser

joe martel said: Communication systems have to balance preciseness with errors. In fault-tolerant and graceful-degradation models the goal is to allow the payload as much imperfection that can be tolerated and not throw the whole thing out. If you look at the HTML coming to most browsers, they almost always have coding flaws, and instead of not displaying anything the tolerant systems try to be as forgiving as they can.

The other aspect is communication systems between services have to deal with proper encoding on one end and proper decoding on the other, and in addition, proper response in but directions. And prioritizing hierarchical data is even more complicated. So in the case of GEDCOM I think the DEAT and BURI are failry high prioirty and instead of throwing out the entire node, or file, because of an errant subfield, it gracefully accepts. Many Gedcom imports will show you the list of warnings, and errors it encountered.

LegacyUser

Tom Huber said: Thanks for your participation, Joe. This has been a very good discussion.

I've invited Gaylon FIndlay (author of the original PAF as well as Ancestral Quest) to this discussion (for his information) as well as sent him a copy of the GEDCOM and a backup of my local database for him to look at. I don't know if he'll participate or not, but at least he is aware of what has happened, not only with the GEDCOM, but also with the AQ to FS connection.

At this point, I am going to correct the two accounts that had errant entries that would have impacted the GEDCOM ingest into Family Tree. I will also run a search on my database to see if there are any others and research those to make sure they are properly recorded in FamilyTree.

Just as an FYI, the errors I have spotted were not found with the GEDCOM import to a new database and they set up the two persons the same way FamilySearch set them up.

The only thing that is, in my opinion, troublesome, is that the problem can be introduced by a user who, like myself, unwittingly put things where they should not have been. Ancestral Quest, when it came to Isaac Karl Post, certainly gave me ample warnings.

But there were none when it came to Eleonora Gay Rasmussen. The system had discovered no problems with my entry of the cemetery in the Buried place field (and it should not), even though I had no Death information in the file. Perhaps this is the one area where the AQ software could be tweaked with a warning that would require valid death information -- date, place, or both -- to be entered.

Newbies who are unfamiliar with the practice of adding both names to a gravestone when the first person in the relationship dies, but no death date for the second person, could easily have done what i did -- entered the cemetery in AQ, even though the user had no evidence the person had died.

But that is on AQ's side of the things. FS already has a living/dead option when editing the Death information in Vitals.

LegacyUser

Tom Huber said: To correct Eleonora's record (in AQ), I moved the burial place to a note and left only the source attached to her record in AQ. That resolved the living/dead situation in AQ. It is not a good solution, but it took care of the situation for the time being.

LegacyUser

Adrian Bruce said: Re adding both names to a stone when only one has died - I don't think that I've ever seen it in the UK. That would suggest there is a risk of any UK based genealogist getting it wrong if they saw an image of such a thing. A risk that actually applies across the board, not just in relation to GEDCOM files. The wide range of the risk does make me worry if any sort of an overall solution is possible... Hmmm

LegacyUser

Tom Huber said: A further note -- on the FS side, Eleonora is still shown as deceased, but there is a case that was created when I switched her to living. It should be reviewed and the record corrected. I suspect that it will show up in the original person's or user's private space...

LegacyUser

Jeff Wiseman said: Tom,

This is just my opinion, but I believe that the way you have resolved this is the only CORRECT way to record the facts that you know. Having a burial place recorded for a person who's name just shows up on her husbands headstone without her death date is NEVER evidence of her burial (even though Find A Grave will still create grave-based memorials for that person).

The ONLY evidence that a headstone appearing like in your example gives, is that when the headstone was place (usually right after the husband was buried), the living wife PLANNED to be buried there when she died. The headstone provides NO evidence whatsoever that she is buried there--therefore, that location cannot justifiably be recorded as her burial location even though her name shows up on the headstone.

Having a headstone for the husband's grave showing his birth and death dates along with his wife and her birth date only is equivalent to many old style headstones where it lists a wife and children, even though they are not buried there (or are still alive). It is no different. The meaning for the wife's name on such a headstone is only evidence that she was his wife. It says nothing about her death or burial.

I have come across headstones like this where the wife PLANNED to be buried their, but due to whatever circumstances, was actually buried a very long distance away in a different location with her won private headstone.

So part of the issue that you are running into with the GEDCOM stuff is simply exacerbated by the fact that the location information in the burial vital should never have been put there in the first place since it is incorrect. The recorded burial location is unsourced and has no documented evidence that it is true. In fact, it is even MORE presumptuous than when FS automatically adds the year of burial to Find a Grave index data.

It would seem to me that if a legitimate burial location is known and recorded in the GEDCOM, then the interpretation that the person is deceased is perfectly legitimate.

But Garbage in, Garbage out.

LegacyUser

Tom Huber said: So true. This is something I'll look for when I run a search on my local db.

LegacyUser

Adrian Bruce said: While we can persuade Tom, I am seriously worried if FS is taking in FindAGrave indexes that include these "only planned" entries. It's not a GEDCOM issue but shouldn't FS be ignoring these only planned entries and not presenting them as Indexes or Hints?

LegacyUser

Jeff Wiseman said: Yes, I am positive that that happens. I suspect that it may not be real easy to automate though. It is mainly in the indexing.

For example, if you have a burial in the Find a Grave index that has no death date, you can't tell WHY there is no death date. It might have been one of these "spousal" type headstones with the death date on it, or it might be a headstone that has a death date that is not readable on the stone, or even not readable in the photo (assuming that there is actually a photo). If there is no photo, the only information that you can get is the location and name--and even THAT is rather tenuous since the Find a grave memorial may not have been created from someone actually visiting the site. I might just be family here-say. (For Find a Grave, if there is no photo, anything on that memorial is mythology (as Tom puts it :-)

Furthermore, we are talking about potentially "Live" persons having memorials created for them simply because their name is on a headstone. Since that data is presumptuous at best, it would require a human being to document the logic associated with that conclusion, so automating it would likely not be a great idea.

LegacyUser

Jeff Wiseman said: The simple issue is that Find a Grave knows that there is a headstone in THIS cemetery with THIS name on it and they have recorded that fact.

Another trick is handling a Cenotaph. These have memorials in Find a Grave as well that list the name and the cemetery, but obviously the person isn't buried there. You have to actually look at the photo and determine how to handle each one.

In Tom's case, if the person was born more than 110 years ago, you can assume that they are deceased and very possibly are buried somewhere else with their own headstone (it's cheaper to add a date to one of those "spousal" type headstones than creating a brand new one). So obviously the location of that initial headstone would not be the burial location. But what do you do if the person was born 88 years ago? Or 50 years? You don't know and they might likely still be alive, in which case you would again NOT use the location of that headstone as a burial location.

LegacyUser

Adrian Bruce said: Hmmm Yeah, rather a lot of options, aren't there?