Source places- Incorrect province listed in many records
I have quite a few ancestors from Hasselt, Overijssel, Netherlands. I have noticed that a lot of the sources I am attaching have the place name incorrectly listed as Hasselt, Noord Brabant, Netherlands in error. Is there any way to change that? It is causing a lot of confusion with users changing the provinces to Noord Brabant because that is what the set place name shows. For example, look at Elisabeth Neeltje Goedkoop (GHGB-4PX). The first source attached to her is an 1885 marriage source. If you click on it once, the indexed portion shows "Event Place: Hasselt, Noord Brabant, Nederland." If you go to openarch.nl and view the original source, image 1 shows the cover of the book, image 2 shows that the province is Overijssel, not Noord Brabant. Many sources reflect this same mistake in the province name.
Can this be changed?
Thank you for your help, Lesa Pringle
Answers
-
@N Tychonievich This sounds like another placename standardization issue. An example from the PID that Lesa mentioned: https://www.familysearch.org/ark:/61903/1:1:QL51-T416
@Lesa M Pringle The clue is the "Event Place (Original) showing that what was indexed has been modified by the computer algorithm. N Tychonievich has taken the lead on getting these problems resolved.
0 -
This a major problem on allmost every indexed dutch record with. I've attached about 80,000 sources alone in these year. In more as 50% of the cases I'm seeing this problem. Furthermore I do have the feeling, the problem is increasingly worsening. I've made it a habbit to check every entry by going to openarch.nl and not rely on the indexed data anymore.
2 -
Another example: See the children of Johannes Laurens Ranneft G436-PYS
In most cases I see "Borne, Noord-Brabant, Nederland" indexed or "Borne, Haute-Loire, Auvergne-Rhône-Alpes, Frankrijk" as standarized place.
In all cases the correct place is "Zenderen, Overijssel, Nederland", which nowadays is part of the municipality "Borne, Overijssel, Nederland". "Borne, Noord-Brabant, Nederland" is nowadays part of the municipality "Schijndel, Noord-Brabant, Nederland.
0 -
Another example Johanna Heino L5LS-RD3
"Den Ham, Overijssel, Nederland" indexed wrongly as "Den Ham, Utrecht, Nederland"
0 -
The examples need to be of the specific record, not of a person/profile, for N Tychonievich to report them.
0 -
Well, he only needs to go to the persons, all sources/records are connected and can easily be extracted.
It's simply a major problem. The number of wrongly indexed records is so huge, that the involved computer algorithm should be withdrawn.
0 -
The scale of the problem has previously been acknowledged here (by a FamilySearch employee), as well as the fact that it was known in advance that the placename standardization exercise would indeed create millions of errors. It seems it was decided this was a small price to pay in relation to the time that would have been needed if humans were to have carried out the work. With that in mind, I think it highly unlikely FamilySearch will withdraw this highly flawed program - regardless of how badly it has impacted on the ease at which we can now find records our ancestors in a website search.
At least your examples still appear as events having taken place in the same country (the Netherlands). Some of us now (eventually) find our relatives with event place names shown as being half way across the world from where the event actually took place!
1 -
Considering the volume of errors to be corrected, anything we can do to make it easier and faster for N Tychonievich is a good idea. Those reports without sufficient information will likely go to the bottom of a very deep pile of corrections.
0 -
... Some of us now (eventually) find our relatives with event place names shown as being half way across the world from where the event actually took place!...
Well, from those l've encountered quite a lot too. 😥
But thank you for the background, didn't know that.
0 -
I get your point. How would you suggest is the best way? Just post a list of all faulty records (in my examples rund about 30 records)? Or every faulty record in a separate Post?
0 -
A record I found yesterday, had Zwolle, Oost Gere, Gelderland, Netherlands instead of Zwolle, Overijssel, Netherlands.
Are all the records with this problem from the province of Overijssel? I mean that the place name province should be Overijssel instead of something else.
I notice that openarch.nl has place names without the province, such as Hasselt, Netherlands or Zwolle, Netherlands. I personally would much rather have that than the incorrect province listed.
Lesa Pringle
0 -
@Lars van Ravenzwaaij N Tychonievich asked that the placename standardization errors be posted in the Search category, as individual posts, not as a list. It's much easier to track what has been corrected and what is still pending with the individual posts.
You can see N Tychonievich's post on the topic here.
2 -
At the risk of sounding like I'm not helping, I'm not yet convinced that this is as simple as the auto-standardisation making the wrong choice out of several. (It could be that...)
To take https://www.familysearch.org/ark:/61903/1:1:QL51-T416 as an example. The "Event Place (Original)" is "Hasselt". Just that. No "Overijssel". How is the algorithm supposed to match this record to "Hasselt, Overijssel", rather than "Hasselt, Noord-Brabant"? (I hope I've got those names right!)
Now, if this was a FamilySearch produced index, then I would have a vague hope that the metadata for that "film" would contain "Overijssel" and the metadata from the "film" would get merged up with the individual index record to come up with the correct "Hasselt, Overijssel".
But do we have the equivalent here? (I am ignoring "Historisch Centrum Overijssel" - that is surely the archives, not the original place, though they do match here). @Lars van Ravenzwaaij looked at the images on openarch.nl and located the correct province from that.
It is perfectly possible that @N Tychonievich and co are way ahead of me and are already looking at this aspect. I don't know - I'm just trying to point people in what might be a profitable direction - or might not. But I am worried about processing files from elsewhere that may or may not contain enough information to feed the auto-standardisation algorithm.
1 -
@Adrian Bruce1 wrote: "I'm not yet convinced that this is as simple as the auto-standardisation making the wrong choice out of several."
It is that, plain and simply. It's pointing out one of the many reasons that autostandardization was and is a miserably awful idea. How is the computer supposed to know what "Hasselt" means? How is it supposed to know what any text string means? The answer is, it doesn't. Sometimes the metadata may tell it more, but as far as I can tell, the bot ignored that wholesale in making its guesses, and there was no sanity check applied afterwards, either.
Taking it further, the underlying cause of this mess -- the attempt at changing the search methodology from text-string-based to what I call entity-based -- reduces the usefulness of searching. If the ship manifest just says "Springfield", it may as well not say anything, because I can't simply search by the string "Springfield" any more: I have to pick one of the hundreds of places by this name around the globe.
1 -
In fact, in most cases I even don't need to open the Image itself. It's sufficiant to go to the openarch-entry and look at the "Source Citation", which, in this cases, shows "Collection Overijssel".
And often there's also a "Note", which shows the correct place.
1 -
Thanks for the info. That would create a fast lot of individual posts then. 🙄
But if @N Tychonievich likes to have it that way, I'll do so.
1 -
@Lars van Ravenzwaaij - thanks for the clarification about where you can check for the desired information.
0 -
@Julia Szent-Györgyi - yes, I actually agree with everything you say. My concern is my fear that anyone conducting an investigation into the auto standardization will assume that the indexing and the metadata are correct, complete and compatible, and will therefore just look at the SQL (or whatever) that combines those and looks for a best fit (whatever that means) in the Standard Placenames. That's what I meant by the "algorithm".
My intention was to urge any review to look beyond the SQL (or whatever) algorithm and look at the whole thing. As I said, it might be that people are already doing that, in which case I can remain hopeful.
0 -
@Lars van Ravenzwaaij If you search for Placename Standardization and filter on my username, you will find MANY posts where I have tagged N Tychonievich to report a problem.
0 -
Thanks. Your report has been added to the list. There is quite a backlog, so we do not know when we will see changes. Thanks for your patience as we get this fixed. As always, I will let you when I get more info.
2 -
Hello,
I want to thank "family search" for all the information that you have made available to us for free! I'm glad that I found this page and realize that I'm not the only one to have noticed errors in the transcriptions of documents from the Netherlands and that they contain conflicting information about the place of the event. For example, many of my ancestors come from Zwolle, and the transcription lists it as being in the province of Gelderland even though the original documents clearly state that the collection is from the province of Overijssel. I've often verified the original documents, especially since I've taken the time to learn the Dutch language, in order to verify the information, but it is not always possible to edit the transcription. I am conscious that some well-intentioned individuals may also edit out correct information without realizing it. Thank you also to all those who have already brought this issue to your attention.
Kind regards,
S(name removed) BRINKHUIS
0 -
As pointed out earlier in this thread, the issue is not transcription/indexing errors. The records were indexed correctly. A poorly-constructed algorithm has done widespread damage.
1 -
@SBRINKHUIS Mod note: Community is a public online forum. For your privacy, your post was edited to remove a name that is not part of your username. Please see the Community Code of Conduct for more details.
0
