Why the difference of information as shown when searching and finding

LegacyUser

W David Samuelsen said: Here is constant oddity of information not matching what is actually recorded.

see the difference between first one (using search by id or by name)


then the actual properly recorded


Did the programmers forgot about the need to extend the updated or correct information to first part?

LegacyUser

DougHo said: Routines like Find seem to display the standardized info (such as Rhein, Prussia). Seems intentional (and reasonable to me, but I suppose subject to argument).

LegacyUser

W David Samuelsen said: It is NOT only that country, even in United States, everywhere! Every country. Even with wrong information.

LegacyUser

DougHo said: If the standardized info is incorrect, then someone needs to go into the person's record and edit the standardized info to be correct. A major reason for such standardization is so that Find works. Again, it can be argued whether the displayed result should be the non-standardized - but I've been trying to explain what you are seeing (the standardized result).

LegacyUser

W David Samuelsen said: Standardization is NOT the issue here. That is not the reason for the Find.

In fact I came across many USA records showing completely wrong data while the actual records showed actual standardized records.

(PlaceStandards team is TOO English centric and still manage to get Rheinland and Rhein all wrong and yet allow Rheinland-Palatine (correct spelling is Rheinland-Pfalz), which is why the Germans and I do not accept Rhein as a province, it's Rheinland. Rhein is name of the river, plain and simple. Again, this is NOT the issue herein.)

Let me show 2 other records, both wrong, too in next message

LegacyUser

W David Samuelsen said: Here's Michel Huppenthal records

first one is Find


second one, actual record


I can tell you flat out, both are wrong on place name. "Losheim am See, Merzig-Wadern, Saarland, Germany" - is 95 percent wrong.

The actual record "Losheim am See, Germany" - still utterly wrong.

Wrong because the place never existed until 1972, part of massive Federal ordered muncipality reorganization.

Saarland? Still wrong, did not exist until Jan 1, 1957, when it was formally named as Saarland and admitted into Federal Republic of Germany.

Merzig-Wadern? It didn't exist until November 1918 AFTER the end of World War I or the Great War.

Correct name for that muncipality/parish? simply Losheim, Merzig, Rheinland, Germany. And before 1 Jan 1870, it was Losheim, Merzig, Rheinland, Preussen, Germany because Preussen became the German Empire on that day.

Again, that is not relevant to the issue herein. The Find should MATCh the actual the individual Family Tree record, instead of misleading us.

As for many entries of Losheim, I have to clean them up because those are part of my huge Britten family. Losheim is next parish to the east. I see same problem with neighboring parishes where my folks are in.

LegacyUser

DougHo said: I guess it is time for me to drop out of this thread. I can only repeat what I said twice before. If you click on the people who you show having different results in the Find result vs the Person card, then click on Edit for the vital which is different, you will see Standardized Event Place which matches the Find result. If you then click on something like See All Changes, you can determine who entered that as the standardized place. If that person chose wrong, you can correct it.

Standardized places seem necessary to me for Find to work for research purposes. When I use Find, I want to be able to enter something which ends up being the same standardization (or close to it) - I do not want to have to know whether I need to type the english version or the german version or full instead of abbreviation, etc.

LegacyUser

Adrian Bruce said: So far as I can see, the first one that you see (the list entry ending in "Prussia, Germany") is the standardised birth-place. The second (with "Preussen, Germany") on the card, is the display birth-place.

It happens for my own grandfather, where the list entries end in "England, United Kingdom" (the standardised) and the card version of the birth-place contains a prefix for the address and terminates with "England" (the display versions).

I have a distinct feeling that an automatic routine has gone through and standardised place-names because there's far too many "United Kingdoms" in my relatives - I never used the phrase for years.

LegacyUser

Juli said: As DougHo said, Find is showing the standardized values that have been associated with the display values shown on the person card. Notice how the Find results spell out the months, while the person card has them abbreviated? Same thing.

If the display value and/or the standardized value are wrong, you need to go onto the person's detail page and fix them.

When Herr Huppenthal's birth information was entered, his birthplace was typed in as "Losheim am See, Germany". Typing this in generated a drop-down list of standardized placenames, and the one that was chosen was "Losheim am See, Merzig-Wadern, Saarland, Germany". (Depending on how and when the birth event was entered, the standardization process may have been non-obvious to the user, so the choice of standard may have simply been the top item on the list.)

This type of "wrong timeframe/jurisdiction" error in standardization is hard to identify, because it doesn't show up on the map (Timeline). But this fact points out another fact: the place isn't actually wrong. The pin on the map is in the right location. It's just the labeling that's inappropriate to the time of the event. There are genealogy websites that _require_ the modern name with modern jurisdictions in order to put the pin in the right place, so count your blessings that FamilySearch does everything possible to support the correct genealogical standard of "name at time of event".

LegacyUser

Juli said: "Standardization is NOT the issue here. That is not the reason for the Find." You're wrong. Standardization is _exactly_ what accounts for the difference: Find shows the standardized value, the person card shows the display value. Period, end of story.

LegacyUser

W David Samuelsen said: the specific names are NOT NOT NOT THE POINT of the original post.

I am talking about the fact there are many personal records actually still original with no changes since created and they do NOT match the "Find" at all.

And what's worse? I kept finding the ones marked as not a match, all because it's either the date or the place a bit off, like British America marked not same as British Colonial America, even everything including the rest of family matched.) I can see duplicates aplenty in "Find"

(the United Kingdom in standard file - is for 1801 and afterwards, and no, the whole thing had NOT gone through for automatic routine of standardizing. - some are so absurd.)

LegacyUser

Juli said: In other words, what you're noticing is that a lot of legacy data in Family Tree has different display values than the associated standardized values. (The fact that one or both of those values is often wrong in some way is a different topic.)

I don't know where the place labels came from in the old extraction programs and such, although judging by the common occurrence of double commas, it was some sort of database or spreadsheet. I also don't know how and when the location entities from the current places database were assigned to that old data. I suspect the answer starts with "it depends".

I also don't know how (or even if) the difference in display versus standardized values affects searching and matching algorithms. It used to be the case that standardized locations and the Places database were used by Find, but not by Records Search, and the hinting mechanisms were in a complicated space somewhere halfway between those extremes. They have been making major behind-the-scenes changes to Records Search, and it is my impression that a big part of that has been incorporation of the Places database into the indexed data. This means that very large numbers of entries have needed to be associated with a standardized location, and there have been correspondingly large numbers of incorrect such associations (such as Ohio being matched to Ohio county in Virginia, or vice versa). The German data is comparatively in better shape: at least most of the labels actually apply to the same place, just at a different time.

LegacyUser

Adrian Bruce said: Juli - for what it's worth (and I don't know if this has anything to do with David's issues) but my impression is that they have been running stuff behind the scenes that updates original place-names with standardised, date "correct", place names.

I don't remember ever seeing any confirmation that the date is a part of it but I think that must be the case now, as I have events in Historical Records originally entered with a placename of Crewe, which have been given a "standard" place-name in Historical Records of Crewe by Farndon - wrong side of the county and a tiny village instead of the big railway town. But the dates are such that the date sensitive alternatives for "Crewe" are "Crewe by Farndon" or "Borough of Crewe". I suspect that "Crewe by Farndon" is regarded as the better match (not unreasonably), explaining the weird data. If one disregarded the dates, then "Crewe" (input) would match to "Crewe" (standard) - but the latter isn't date appropriate.

Like I say, I really don't know if this explains David's stuff but he does mention "records actually still original with no changes since created and they do NOT match the 'Find' at all". If the data displayed in the "Find" has come from one of these recent(?) background runs, that might explain matters???? (Of course, we can't tell from the Change Log because background updates don't go into the Change Log. Ahem. No comment)

LegacyUser

W David Samuelsen said: Juli, you're almost to the point of the original post.

The question, why can't the FIND match the person's page information?

At least we won't get snookered into personal pages only to discover either one may be right or wrong, or worse yet, both wrong, requiring constantly cleaning up to find there's duplicates that are incorrectly marked as not matched.