For some value of "exact" that I am completely unfamiliar with.
LegacyUser
✭✭✭✭
Juli said: https://www.familysearch.org/search/r...
I put in Kékcse, Szabolcs, Hungary for the birth location and checked the "exact" box. The first and fourth results (among others) are from Kércs.
Kékcse and (Nyir)Kércs are over 15 miles from each other as the crow flies.
Why is it ignoring the "exact" checkbox like this?
I put in Kékcse, Szabolcs, Hungary for the birth location and checked the "exact" box. The first and fourth results (among others) are from Kércs.
Kékcse and (Nyir)Kércs are over 15 miles from each other as the crow flies.
Why is it ignoring the "exact" checkbox like this?
Tagged:
0
Comments
-
-
Adrian Bruce said: According to the FS Standard Placenames database, Kékcse is an Alternate Name for Nyírkércs, Szabolcs, Hungary (see URL https://www.familysearch.org/research... ) In the Citations for Nyírkércs it refers to "Book - ReferenceHungaryDvorzsak1881, 208061 - Kékcse" but I have never understood what on earth those citations mean, which tends to make them useless, so I've no idea whether the alternate is justifiable or not.
https://www.familysearch.org/research... shows "Kékcse, Szabolcs, Hungary" which only has what this Englishman would consider minor spelling variants for Alternate Names.
So the way I understand the system to work, it looks for "Kékcse, Szabolcs, Hungary" in the standard place-names, and find two because it looks in the Alternate names as well. Both qualify under exact matching, I am guessing because there is no truncation to "Szabolcs, Hungary". It then does the search using both - whether it uses a search by text of the 2 place-names or a search on the 2 id numbers, I've no idea.
That's my understanding of why this happened. As to whether it should happen, well, I don't think so. We, the users of FS, ought to understand that if we enter "Nantwich, Cheshire, England" in an exact search then we should not expect to get records for "Namptwyche, Cheshire, England" back.
I'm sorry but this is dumbing down because it removes the responsibility for our inputs from us in the belief that we are not competent.0 -
Adrian Bruce said: That's strange. I presume that the "Szabolcs, Hungary" remained on the end of the place-name. So the search must have failed to find a standard place-name for gobbledygook, Szabolcs, Hungary, as a result of which it truncates to Szabolcs, Hungary and finds plenty of such places.
Truncation is surely a nonsense on an exact search! In a sense this is more worrying than Juli's original example because at least the Alternate Names lead us there in her example.
Am I misunderstanding how the search works?0 -
Adrian Bruce said: I suspect that FS, if it wants to go down this route, needs to have multiple values for that place-name "check box". (just go and look at Ancestry!)
Possible values:
- Exact - will search only for that exact text (in full) or, if it's a standard place-name, for other place-names on the place to which the place-name refers. The standard place-name not to be found using alternates, etc, but only through exact matching on the full text of the standard name.
- Exact and Similar - as above but now the search for a standard place-name to allow alternates, etc.
- Match on next higher level - allow left truncation so instead of searching for "Kékcse, Szabolcs, Hungary" it searches for "Szabolcs, Hungary" and allows all places with that name in full. Only one level of truncation
- Match on all higher levels - searches for "Szabolcs, Hungary" and "Hungary".
That's written from my understanding of the current search which may not be quite right.
Further examples:
- Exact search on Nantwich, Cheshire, England finds that and Nantwich, Cheshire, England, United Kingdom, but not Namptwyche, Cheshire, England (if that is still an alternate)
- Exact And Similar search on Nantwich, Cheshire, England finds that and Nantwich, Cheshire, England, United Kingdom, along with the Namptwyche variant spelling of Nantwich.
- Match on next higher level on Nantwich, Cheshire, England find all records with place-names ending in Cheshire, England or Cheshire, England, United Kingdom. But not (say) place-names ending in Lancashire, England.
- Match on all higher levels on Nantwich, Cheshire, England find all records with place-names ending in Cheshire, England or Cheshire, England, United Kingdom, and all ending in England or England, United Kingdom.0 -
Juli said: "Dvorzsák" is a gazetteer, and he makes no mention of "Kékcse" under Kércs:
https://kt.lib.pte.hu/cgi-bin/kt.cgi?...
Just to make sure, I checked Kékcse, and there's no mention of Kércs:
https://kt.lib.pte.hu/cgi-bin/kt.cgi?...
So this is an error in the places database which I will need to correct. (I Have Powers! Bwahaha!)
Adrian, thanks for finding that bit about the (incorrect) alternate name. I don't know why it didn't occur to me to check for that sort of thing.0 -
Brian Rhees said: "exact" place searches work a little different than is usually expected.
Any place searches are sent through a standardization process to attempt to find an actual location that has a chain of parent locations (county, region, country, etc.).
When you run a non-exact place search it finds a place that matches your search term "Kekcse, Szabolcs, Hungary" and will return results that were found within each of those place levels. The places found closer to the exact search are weighed higher in the results. Generally you'll see results in the exact place higher, then places in surrounding cities within that region, then matches within the country way down in the results.
When you select an "exact" match for a place name it filters out results from surrounding areas; BUT may include results from locations more specific than the one specified. (e.g. if you searched for "Szabolcs, Hungary" exact match you'll still get a hit for the record that has a birthplace of "Kekcse, Szabolcs, Hungary".
In the goublygook case you'll see standards was still able to identify the region to search in; even though it couldn't find the goublygook city: https://www.familysearch.org/research...0
This discussion has been closed.