OK, so what the heck is the "exact" checkbox on places actually _doing_ (besides apparently absolute

LegacyUser

Juli said: This is Records Search.

I put in "Garansek, Banská Bystrica, Slovakia" for the birthplace, because that's what the metadata has for the indexed baptisms that I'm searching through. (The place was Garamszeg, Zólyom, Hungary.) I check the "exact" box. (https://www.familysearch.org/search/r...)

Among the results:

Divín, Lučenec, Slovakia (Divény, Nógrád, Hungary)
Dolné Rykynčice, Krupina, Slovakia (Alsó-Rakoncza, Hont, Hungary)
Želovce, Modrý Kameň, Slovakia (Zély, Nógrád, Hungary)
Zvolen, Zvolen, Slovakia (Zólyom, Zólyom, Hungary)
Kremnica, Kremnica, Slovakia (Körmöcbánya, Bars, Hungary)
Janova Lehota, Kremnica, Slovakia (Janó-Lehota, Bars, Hungary)
Breznička, Lučenec, Slovakia (Berzencze, Nógrád, Hungary)
Šahy, Krupina, Slovakia (Ipolyság, Hont, Hungary)

What the *&^%??

LegacyUser

Robert Wren said: Ahh, Julie, the poor checkbox isn't doing anything.

It's just sitting there waiting for someone to click in it.

Which YOU did, now it is satisfied, and gave you 18 matching results; before you clicked on it it gave you less than 20 - but it's still happy, and you should be too.

Poor little checkbox.

LegacyUser

Tom Huber said: "Garansek" is a problem. I did a search for the place in the standards list (https://www.familysearch.org/research...) and Garansek is not in the list. As such, that may have impacted the index with respect for searches.

You may want to contact the teams involved at PlaceFeedback@familysearch.org and reference this discussion.

LegacyUser

Juli said: Tom, if the problem were in the places database, I could fix that myself. (I have Powers. Of a sort.)

As I said, the misspelling is what's in the index metadata. (And in the Catalog.) It has been thus ever since the index was made available, many years ago. Formerly, I could work around this error by simply using what's in the index in the search field, never mind that it's spelled wrong.

Now, I put in exactly what's in the index, and tell it to look for exactly that, and it gives me ...a random assortment.

Regardless of the underlying metadata error, there is also an error on the search interface's part: I tell it "exact", it returns "whatever".

LegacyUser

Juli said: Huh. Hungarian Wikipedia claims that the Slovaks did call it Garansek from 1927 to 1945. Dunno how they got to that, given that the local river is the Garam.

But as I said, what is or isn't in the places database should have no bearing on whether the search returns what I told it to look for.

LegacyUser

Tom Huber said: It is true that it may not have a bearing on the search routines, but I believe there are plans to make use of the list with its name variations if that has not already been implemented. Lundgren will have to clarify, since he is active on this site and involved with search engineering.

LegacyUser

Paul said: Okay, it did PRIORITISE the 18 results that matched the input, but it still should not have offered the other 239. Prioritisation should only be on dates, not place names. I tested on different place names (in England) just now and got the "exact results" expected.

LegacyUser

Brian Rhees said: Hey Juli and Tom.

It looks like it is the "Garansek, Banská Bystrica, Slovakia" place causing the confusing results in this case.
Looks like Juli (or somebody aware of this thread) updated the place database for Garansek today that will fix this problem the next time the data is reprocessed. Before that fix it was unable to find a specific place and instead returned the region of "Banská Bystrica, Slovakia".

Because the search only standardized to "Banská Bystrica, Slovakia" even with an "exact" search it still was returning places that were categorized below that region. The other place names in the results don't look like they do immediately, but when they are sent through standards they all standardize to places within that region:
- Divín, Lučenec, Banská Bystrica, Slovakia
- Dolné Rykynčice, Krupina, Banská Bystrica, Slovakia
- Želovce, Veľký Krtíš, Banská Bystrica, Slovakia
- etc.

You'll notice in your search results places that were indexed with an exact match of "Banská Bystrica, Slovakia" were returned first followed by places that were indexed as sub-jurisdictions.

LegacyUser

Juli said: If you're going to rewrite the search to ignore the text and go by the location, then you're going to have to go through those millions of index entries and fix all of the place texts.
Every. Single. One.
Millions upon millions.

LegacyUser

Jeff Wiseman said: Maybe it's like the "Close Doors" button in most elevators that is not hooked up to anything?

LegacyUser

Juli said: Contemplating the sea change in search philosophy alluded to in Brian Rhees's comment, I just cannot see how this will ever turn out anything other than Really Badly.

If I tell the computer to search for exactly "thingamabob", I expect it to return results for, well, _thingamabob_. Not "whatsis" and "doohickey", no matter how similar they are in meaning.

If the database has it as "thingymabob", then my search for exactly "thingamabob" should return no results. But if I know that the database has it as "thingymabob", then my search for exactly "thingymabob" should have results: all of the instances of "thingymabob"-- and nothing else. Any related things like "whatsis" and "doohickey" should not even enter the picture unless I uncheck the "exact" box.

Extending the analogy: say I'm searching for "thingymabob, gadget", because I know that's how it got spelled in the database. But the new search algorithm isn't actually looking at the text of the database; it's only looking at how the text has been categorized. The available categories include "Gadget", and under that the three items "thingamabob", "whatsis", and "doohickey". When I tell it to look for exactly "thingymabob, gadget", it checks for and finds the Gadget category, but not Thingymabob under it. So it returns everything that matches Gadget exactly.

I'm sorry, but this is just BAD design. Absolutely miserably awful.

LegacyUser

gasmodels said: I guess, I agree with you Juli. I have had similar issues maybe not as severe as you encountered. But when the historical record entry says one thing and the so called standardized location is something else and I want to search for the original record, it seems illogical for the system to choose a standardized location to use for the search when the record I know that information is on the record. I also hate the system automatically truncating the location when I search from the person page. I find for almost every search I complete, I have to redo the location because of the stupid termination. I do not want to search all of England, United Kingdom when I am specifically looking for Royton, Lancashire, England or some other specific place. I really do not understand why the developers think they are improving the search with their changes. It appears to me they believe their results are improved because the number of returns are increased not the number of matching records to the search criteria.

LegacyUser

Tom Huber said: Is there a discussion thread for the truncation problem? (I think I remember something along those lines, but my memory is not sure any more)

If so, can you provide a link?

If not, a new discussion thread should be opened to make the development teams aware of the issue and get the truncation problem addressed.

LegacyUser

Paul said: There have been several over the years, Tom, and it has been several years since the changes were made that created the "truncation problem".

The main reason the issue is unlikely to be addressed is, just as with the recent move (seemingly) to discourage "exact" searches, the developers' belief is that it is generally better that users are offered a much broader set of results. This has been confirmed by comments FS employees have made on this forum in relation to both issues.

Whilst it is true many relevant results MIGHT be lost if (1) the truncation issue was dealt with (e.g. by dropping the "United Kingdom" suffix carried across from the person page) and (2) if the "exact match" boxes were not checked, I believe the opportunity to NARROW the search to give the far more likely "results" should always be the primary objective.

To re-emphasise the point, these ideas do not seem to coincide with the developers' thought processes. However, I do not wish to be too critical here, as they seem to be making these "enhancements" for the benefit of the less-experienced (dare I admit "average") user, rather than accommodate the needs of the more experienced.

My current "fear" remains the possibility the "Exact matching" facility will be withdrawn altogether. Lundgren pointed out the fact that the Search page can appear in two "formats" at present: one with the "exact match" check boxes still alongside the various input fields, the other with these removed and the "Exact matching" option appearing further down the left hand side of the page. I'd obviously request them to dismiss any possible thoughts of removing the option altogether.

LegacyUser

Lundgren said: We are not planning on removing the exact search functionality.

The narrow, or truncation, behavior has not changed in at least 8 years.

LegacyUser

Paul said: Thanks for confirming the "exact match" position, Lundgren. Very relieved.

On the truncation behaviour, I believe you must know how long it's been this way, from the time you've been connected with the process. It seems nowhere near that long to me, but time really must fly by as you get older!

LegacyUser

gasmodels said: I am of the same opinion Paul, I believe there was a change to only the two highest levels something like 3 years ago. I get so tired of having to edit -- England, United Kingdom to something more useful. When working on a particular messy record - I have even temporarily edited the birth location so that I won't have to keep changing when searching. It is clearly and impediment to my research.

LegacyUser

Paul said: Yes, providing we are not talking at cross-purposes, Lundgren does seem to be mistaken about how long it has been since the truncation behaviour changed.

I just found the topic at https://getsatisfaction.com/familysea..., which was raised "over 2 years ago" and deals with an issue that had only recently been noticed by users at that time. Note particularly Robert Kehrer's post in this thread.

Changes obviously were made between 2 and 3 years ago.

LegacyUser

Lundgren said: You are correct. I misunderstood your "truncation" problem. I thought it was related to the way places are standardized and treated as a hierarchy. (The main point of this original post.)

As for the "truncation problem" as you describe it is a bit of a hijacking of this thread.

We are concluding our study that was done for the "Search FamilySearch Records" button from tree. (We recently requested input here: https://getsatisfaction.com/familysea...)

We will provide direction to our user interface teams that create those searches soon.