The new Linker has a bad, bad habit
I noticed that the Source Linker is really trying hard to connect a geographic listing to one in the Family Search database of "Standardized" locations.
But it turns out that it isn't always doing a great job. I had been hoping for the best, but it appears that all this is going to do is make errors worse.
It's faster, yes. But take this example for Brazoria, Texas. It should be rather obvious to most people where this is geographically - Google will find it every time. Especially when the source gives a Zip Code, there is no doubt where this town is on the Texas coast.
But in Source Linker, it pulls in some obscure "Freeport" near Lubbock, some 600 miles away and it is easy to ruin the link to indivuals. As far as I can tell, Hale County does not have a Freeport, at least not now. Source Linker defaults to this Hale County obscure, enigmatic town, and the user, not being one to argue with slick, seemingly accurate geolocating, is often none the wiser.
While this particular oddity in the great State of Texas should be fixed by the powers that be, there are several meta "questions" that I have for staff at FamilySearch.
- Why is there no "report problems with this record" available on Source Linker?
- Why is the user presented with a guessed location - either by default or by filling in the information as if already fact-checked?
- Can you fix Source Linker by having a selection method that asks and informs the user of a geographical ambiguity? Example: Counties that are similar (Deaf Smith vs. Smith County), Counties that are also the name of the State (Arkansas County), Cities that are the same as a County (Houston County or Houston the city), and Cities that are located in multiple counties (Katy, Texas), and my favorite - rural towns that use a post office in a different county. There are also counties which change their boundaries over the years.
It doesn't do any good to use incorrect standardized places, does it?
Answers
-
I suspect this is part of the much wider placename standardisation issue that is discussed on many Community threads.
@SerraNola one for you please.
1 -
I agree with Mandy that this one is not at SourceLinker's door, but at the automangler's. That's what I call the automated algorithm that is responsible for destroying FS's place data by trying (and failing) to associate text fields with the correct database entries.
The reason Source Linker doesn't have a "report problems with this record" button is that Source Linker is neither the index entry nor the index editor. What it does have is a "View Record" link, which is how you can get to the "Edit" button if available, or for some third-party indexes, a "report a problem" button.
1 -
Well, I actually meant that a "report problems" link would help point to an issue with Source Linker's utilization of the records. At some point, the Linker is reading the indexed data and interpreting it. You see on the left something like "Freeport, Texas" and then when you add it to a person, it magically changes it to the wrong county. This sleight of hand should be reported on the relevant page, if you ask me.
Maybe a "report problem with the Source Linker."
There is not another place to see this problem happening, or at least I don't think the standardization is happening on the source page.
I try my best to fixes sources, too, but in these cases the sources are pretty much right. It wouldn't seem logical to go fix a source that already says "Freeport, Texas" as its index. Your suggestion is therefore a bit short on usefulness.
We need FS to tackle the several issues with standardized locations. This Source Linker bug is one where the rubber meets the road. You can watch it fail miserably, unlike when you are typing in a location in the birth place field where it seems to be helpfully suggesting locations. Source Linker is automatically doing stoopid things to the data without a drop-down or choice.
0 -
I don't quite understand the specific problem you are connecting to the source linker. As explained, most of the issues around incorrect locations appearing in FamilySearch records relate to the auto-standardization exercise, which has caused corruption of the originally recorded locations.
With regards to the new source linker, I find I can now immediately make corrections to the placenames, rather than only having the previous option of doing this on the profile pages.
As illustrated, there is a drop-down, although - alternatively - one can manually change the placename to whatever you feel is the correct / original version. As explained, the actual problem does not directly relate to the source linker, but is an area which is obviously affected by the overall problem.
Although this is not a very good example (the alternatives in the drop-down all appearing in the same format), you say:
"Source Linker is automatically doing stoopid things to the data without a drop-down or choice"
whereas, a great advantage in this new version is the option to edit details does exist.
1 -
Here's a better example: if I want to change the format of the place of residence to how it was in 1911 (rather than post-1996, which was how it had been carried across to the source linker), I merely delete the wording after "Naburn" and am then given my options, from which I select the third one in the drop-down:
1 -
@WuNee, can you give a link to an index entry where the incorrect autostandardization is only occurring in SourceLinker?
My experience matches Paul's: the error is present in search results, the index detail page, the hint summary, and of course in Source Linker. There have, however, been cases where the mangler was being applied "on the fly" on Search results lists, resulting in ludicrous claims (such as people dying on one continent and being buried on another) which were not reflected on the detail pages for the individual results. I would not be entirely surprised if this were occurring in Source Linker now; I just haven't seen it.
If it is Source Linker running the mangler separately, the place to complain about it (with specifics, if possible) is the Source Linker Feedback group.
2
