Data in Source Linker and Indexed data being Linked Do Not Match

LegacyUser

Jeff Wiseman said: For some time now I have been noticing that data provided in the Source linker from a given source does not match that when you actually look at the index data. The following example is just one of those. It is taken from the US SS Death Index. Apparently only the death DATE exists in the record with no death PLACE.

I can't imagine why a Death Index would be missing a death location. However, the source linker seems to be smart enough to figure it out on its own so that the death location can be transferred over into the record the index is being attached too.

However, it DOESN'T seem to be smart enough to guess the birth location, even though it is actually given in the index record!

Kinda wondering what's going on here...

LegacyUser

Tom Huber said: The US SSA death index does not include the place of death, only the laser known address of the person,

It is this way on all the sites that publish the death index, and always has been.

LegacyUser

Tom Huber said: Last known... blame my iPad

LegacyUser

Jeff Wiseman said: So how in the world does the source linker know that this death was in Florida?

It's impossible for me to know if the "State" in the record (Indiana in the example I gave) is for the Birth or the Death.

LegacyUser

Jessie Hearle said: Jeff, in my experience depending on the year of death, the social security death index will report the last know address
But in your example above, “Indiana” could be the state where the person first obtained a social security number (state issued) rather than birth state

For example, my mother-in-law was born in Illinois, but grew up and began working in Missouri. The SSDI on FamilySearch lists her birth date and issuing state as Missouri.
Ancestry has Social Security Applications, I find much this index much more useful. The application index lists her birth city, not just the state. It also includes both parents names. For women who have name changes due to marriage, those are also listed if they were reported.

LegacyUser

Adrian Bruce said: I have a distinct feeling that I have also noticed differences in content - what I can't remember is where I saw the differences - there are 3 spaces where content can be seen - Search Results; the "card" containing the indexed values and the values seen in the source-linker. Something in those 3, somewhere in some collection, had differences in values (and I don't mean that some items were only on the "card", that's expected by me).

I did look to see if I'd raised this before in GetSat but rapidly lost the will to search - in fact I have a suspicion that I wrote the thing up but deleted it as it was an incidental to the main query.

LegacyUser

Adrian Bruce said: I suspect that my issue was with the SSDI - I'll put these screen-shots in just to show it's not a one-off and also show all 3 places that I talked about above.


This is the item in the Search Results - you would believe from the construction of the screen that Per died December 1981 in San Jose, Santa Clara, CA.


When you look at the "card" showing the values, it is made clear there that San Jose is the last residence, not the place of death (which I suspect was not in CA as I can't find him in the California Death Index). NB - the "State: California" line refers to where his number was issued - certainly not where he was born (which was Denmark)


Finally we have the source-linker view, where it does look like it's showing the death place as San Jose.

So it does appear that San Jose is being represented inconsistently and incorrectly given that the SSDI doesn't include death place (so far as this Englishman knows!)

LegacyUser

Jeff Wiseman said: Jesse,

Thanks for that. I think that the original issue still exists though. The data in the source linker should be a subset of that shown in the record. These don't match. Furthermore, the data that is there is ambiguously labeled, so who knows what it means. Furthermore, when the source linker allows you to copy this data over to the person's record, the data coming across might have nothing to do with the attribute it is being placed into in the person record.

The previous postal code of 33450 has been decommissioned, but it would have originally been in Florida. So if THAT is where the Florida Death location in the Source linker came from, it is presumptuous and should not be identified as the location of death by the source linker. Why is the label of "Death" in the source linker shown as "Event Date" in the actual record? They are not necessarily the same.

Your comment about the state of Indiana is likely true though. All previous records show his birth place as being in Herrod, Allen, Ohio which is only 40-50 miles from the Ohio/Indiana border. But when you have a label of "State" in the record display, the only clue that you have for what it means has to be taken from the list of the record fields. Since it follows the Birth field, people will typically assume that it is the birth place. Fortunately it does not get pulled through into the source linker. This kind of ambiguity is rampant on this website though. If "State" in this instances really means "State of SS Registration", then LABEL it that way! Call a spade a spade.

Unfortunately, I do now understand that I cannot trust any labels used by FS relative to the US SS Death Index anymore. The Death location provided by the Source linker and copied into the person record cannot be trusted as it is a presumption only.

LegacyUser

Jeff Wiseman said: Thanks for that further example of the inappropriate and misleading labeling being used in these windows. I hope FS looks into this because it's bound to confuse others.

LegacyUser

Adrian Bruce said: If I understand anything about the SSDI (or whatever it's called) it's thanks to Ancestry, not the labels on the FS screen!

It might be that the FS Wiki contains information that's just as good. But why would I go there if it looks fine in Source Linker? It only looked dodgy to me personally because I'm a slightly cynical pedant with years of practice testing and debugging software! Others might take things at face value.