What a difference a wildcard makes!
This clearly illustrates how users can encounter the difficulty of either getting no results in a search, or a large amount. Regardless of the fact that filters and other added details (dates, collections, etc.) can be of help, a "basic" search must prove very baffling to the inexperienced user:
Search results without a wildcard:
Search results with a wildcard added after the placename:
How on earth is anyone supposed to divine how to enter that search?
Bear in mind that the Standards database pops up 5 different Birminghams that are all in what is now the West Midlands, so anyone would be justified in slightly panicking and not choosing one.
I suspect that it doesn't matter which one is chosen - I chose Birmingham, Warwickshire, England, United Kingdom, the Poor Law Union variant. Firstly I got Marriage Registrations there, which I assure you are not part of the Poor Law records - at least, not 65 screens of them. Then I got stuff for 1982, several years after Birmingham had ceased to be part of Warwickshire and become part of the West Midlands. That's incorrectly indexed, but it does illustrate that the question of which Birmingham to choose is non-trivial for both the software and the user.
And yes, it does give answers before 1801 when Birmingham was in Warwickshire, England, although again that's down to the indexing for both Event Place Original and Event Place.
To return to Paul's input, it seems to me to be a logical first go for a user to enter Marriage Place = Birmingham (with exact ticked). I would think it reasonable for the system to respond to that with marriage events in any and every Birmingham across the globe. But it gives none at all.
Err - but isn't "Birmingham" the same, logically, as "Birmingham*" ? So why does "Birmingham" (nothing else apart from the name) give different answers (none) from "Birmingham*" (nothing else apart from the name) (65 screens)
Well, I can't explain the logic so who can?0
I had a further thought for experimentation.
I entered surname "Cooper" (exact), and marriage place "Barthomley" (exact) - notice no wild card. I got three pages. Isn't this exactly the same type of criteria as "Birmingham" exact, which gave zero answers...?
The same query with "Barthomley*" also gives 3 pages.
So why is one "single node place-name" query (Barthomley) successful, but another "single node place-name" query (Birmingham) unsuccessful (giving zero results)?
Note zero results - not "Too many so that we can't display" - not according to the screen,0
Of course the other option would be to have a proper search algorithm for free text input in the place field.
The search input of birmingham should search for that and that alone. Other inputs in the place field should be ignored. Using the places database in this case is utterly inappropriate. It is far too rigid. It is far too incomplete (even for somewhere with comparatively good coverage like the UK). The auto-"match" algorithms that have been used to "standardise" the raw transcription data for records have an appallingly high error rate and when a match problem occurs it pollutes an entire section of data in transcribed record collections. For example St Mary's Warwick as a raw census residence results in a "standardised" residence in Handsworth which is nearly 30 miles away.
The places database is being shoehorned into use in areas it is absolutely not suitable for. It significantly degrades the search experience, sometimes to the point of uselessness.1
"The places database is being shoehorned into use in areas it is absolutely not suitable for. It significantly degrades the search experience,"
I am certain that you are right about the basic principle of standardising places in Historical Records being counter productive. Having the auto standardisation algorithm in the background puts the icing on that cake - though "icing" is not the word I'm thinking of.
If we reverted (?) to a straight text search of both original and standardised places, then the user would need to think how to deal with all the Birmingham, Alabama entries. (If they can't deal with that then....)
The only point I'd add would be that if someone typed "Birmingham, England", the search should be for the two separate text strings of "Birmingham" and "England" logically Anded together, rather than the single string "Birmingham, England" because that is unlikely to occur. (Though it will).
Otherwise the indexing programme will never catch up - not least because people didn't always use standard placenames in the past.0
Julia Szent-Györgyi ✭✭✭✭✭
The whole autostandardization situation was caused by FS's decision to transition to a different search method for dates and places; we're just seeing the final nails in the coffin of text-string-based search for these fields.
If they were to reverse this decision, removing every autostandardized place, and reverting to string-based search in all fields, I would be very, very happy -- but I know that it's not going to happen. FS has made its decision and the changes are here to stay. We're all stuck using alternate methods for localizing records searches for the foreseeable future.2
"for the foreseeable future..."
Let's hope the foreseeable lasts as long as the usual iterations of a User Interface...0