Why this inconsistency in providing Research Help Record Hints?
I am regularly encountering the issue found at GBYC-GTC. In spite of my having inputted Middlesex instead of London as the county of birth / death, a record hint is produced for the Death Registration (including London as the county), but not for the Birth Registration (which has the same placename format).
Why this anomaly? The circumstances appear identical, so why not offer either both available sources or - alternatively - not offer the one relating to his death?
This is an issue I have experienced on numerous occasions over the last few days - each time the hint being offered for the death-related source / record, but never for the relating to the birth registration.
Update - I just did a test on a sibling (GBYC-NYF) who also was born / died within the same year. I changed both placenames to Islington, London, England, United Kingdom, but still am only offered the death registration record as a hint, in spite of both items being at the top of the Results page at https://www.familysearch.org/search/record/results?treeref=GBYC-NYF&q.givenName=Richard&q.surname=Betjemann&q.birthLikePlace=Islington%2C+London%2C+England%2C+United+Kingdom&q.birthLikeDate.from=1903&q.birthLikeDate.to=1907&q.deathLikePlace=Islington%2C+London%2C+England%2C+United+Kingdom&q.deathLikeDate.from=1903&q.deathLikeDate.to=1907 . So I remain mystified as to why only the death reg. hints are being offered here, and not the birth ones.
Best Answer
-
I think the birth registrations index hasn't been fed to the hinting engine: filtering the search to just that collection results in no profile icons, just the piece-of-paper ones. I also tried broadening the filtered search and saw only "attached" and "details" icons on the first five hundred results.
1
Answers
-
Yes, that makes sense. To be honest, if this is the case, I'm quite happy the death registrations have been prioritised, as (from my experience) birth records are far easier to find (having census records to work from, too) than death ones - especially where a death might have taken place quite recently.
0 -
I can't unravel what's happening either. I tried pressing the Search button from the child's Profile and didn't see his birth until I changed it from "Islington, Middlesex etc" to "Islington, London etc". The only other thing I can suggest is that the hinted Death is to an Event Type of Death, whereas the Birth (when I found it) has Event Type Birth Registration.
Maybe, definitely maybe, the ranking significance of the Death event (for a Death search) is higher than the ranking significance of the Birth Registration event (for a Birth search), with the latter needing a closer match on Place to get there. Or maybe I got lost in the variations…
2 -
You make a good point about the difference between the way birth registrations continue to be treated - as custom events - compared to how death registrations are now treated: as vitals. I believe this could well have a bearing on this issue.
On the matter of "Middlesex" v "London", I am surprised that (without even the "Exact" box being checked) the search algorithm is failing to see the connection and not producing as a result what I (we) would consider a very close match. As this surname - Betjeman(n) - is quite rare, I have been carrying out my searches on the placename "England, United Kingdom", to ensure a greater chance of seeing the expected results produced. Even still, my searches have proved the "less is better" theory about making searches: in that I have also been making it a practice of searching for one event (birth, marriage, death) at a time.
It is seems so strange that (at the one extreme) we seem to get thousands of totally irrelevant results returned, yet otherwise can end-up with problems in getting returned what seems (to us) such obvious matches to individuals, whose sources we were confidently expecting to appear at the top of the list!
3 -
I just experimented with "Middlesex" v "London" for Stanley Betjemann, GBYC-GTC. (Note - the changeover from Middlesex to London for administrative purposes happened in 1889).
From his profile page (and without altering anything I hasten to add!) I hit the Search Records button for FamilySearch. The basic response gives 631 results. This is with his birth and death locations set (as now) to "Islington, Middlesex, England, United Kingdom".
On the resulting search screen (not the profile!), I then altered both "Islington, Middlesex, England, United Kingdom" to "Islington, London, England, United Kingdom". This gives 2,316 results.
I investigated further by setting both search screens to have Principal on Record set to Yes.
The search with birth and death locations set to "Islington, Middlesex, England, United Kingdom" went down from 631 results to 71. I can't be certain but in those 71, I didn't see a single result referring to any variety of Islington.
The search with birth and death locations set to "Islington, London, England, United Kingdom" went down from 2,316 results to 88. The first two are for Islington, London, and are, I suspect, both Paul's chap.
It therefore seems clear to me that something in the search process is refusing to equate "Islington, Middlesex, England, United Kingdom" from the input query with "Islington, London, England, United Kingdom" on the files.
This, if I'm right, is FamilySearch shooting itself in the foot. (Please tell me if I'm missing something.) Effectively, FS has required us to standardise on the chronologically correct "London" version of Islington for 1889 or later. (And presumably "Middlesex" for before…). Has this been publicised? If we don't standardise the placename by date, then it appears from the Islington test, that we won't get the "correct" answers.
I can see lots of potential issues with this.
- Lots of profiles are currently set to date-inappropriate values - just because of history.
- Lots of researchers deliberately use "Middlesex" instead of "London". It is important to their personal story that their ancestors thought of themselves as living in Middlesex, even after 1889.
- I can envisage that a profile might have just one placename - say "Islington, Middlesex" for a pre-1889 event. Do we have to do two searches to make it look for "Islington, Middlesex" and "Islington, London"?
- It appears to me that I can update a Place Name on a Profile to a date-inappropriate value and not get warned, even though the press-the-button search won't give the right answer (e.g. I just set a 1954 date to "Islington, Middlesex, England, United Kingdom" and got no warning).
- Conversely, note that I have only tested the "Middlesex" v "London" issue for Islington. I have no idea if "England" v "England, United Kingdom" is an issue, nor if there is an issue with (say) Warrington moving from Lancashire to Cheshire in 1974 - but if Islington doesn't straggle the time boundary correctly, why would Warrington?
Am I worrying too much? 71 versus 88 says not… But is there something specific to Islington?
2 -
Re my bullet:
I can envisage that a profile might have just one placename - say "Islington, Middlesex" for a pre-1889 event. Do we have to do two searches to make it look for "Islington, Middlesex" and "Islington, London"?
On reflection that misses the issue - having "just one placename" is irrelevant. Suppose I am searching for birth, christening, etc records of someone named John Betjeman, who I know was born in Islington, roughly about 1890. My standard tactic will be to look in the years 1880-1900 (i.e. 10y either way).
I ran 2 Search / Records queries in FS looking for
Name = John Betjeman
Principal on Record = Yes
Type = Birth, Baptism & Christening
Birth Place (1st) = Islington, London, England, United Kingdom
also (2ndly)
Birth Place = Islington, Middlesex, England, United KingdomThe "Islington, London" query gives 81 results.
The "Islington, Middlesex" query gives 20 results.
I suspect I may be behind the times here but I had not realised that the 2 queries would give such different results - to me, Islington is Islington is Islington and both should give the same result set.
Clearly to pick up both the pre-1889 "Islington Middlesex" AND the post 1889 "Islington, London" results, I need to run 2 queries - despite the 2 names simply being different periods of the same underlying place.
The situation may be complicated by the fact that the underlying historical records don't match the 1889 changeover. I found a Birth Registration in 1884 at "St. Saviour Southwark, London, England" registration district despite the fact that it was "St Saviour Southwark, Surrey, England, United Kingdom" up to 1889.
1 -
It is my impression that half of FS's indexes used the jurisdictions that were current at the time of filming, and the other half used whatever the place was at the time of indexing — but both have now been fed to the autostandardizer, resulting in large swaths of useless locations (a Hungarian civil registration took place in Hungary? Gee, really?), swaths of utter nonsense (Argentina in South Carolina), and all sorts of struggling little islands of almost-but-not-quite (Middlesex versus London).
As I understand it, the way it's meant to work is for every location in the database to have all of its possible names and jurisdictions connected, so that searching for Islington, Middlesex will turn up anything that took place there, even if it's labeled as Islington, London. Problem is, it's not that simple. For one thing, once it got absorbed into the city, people stopped using "Islington" and just called it "London". Given that possibility, is the search supposed to return everything that's labeled "London" when you search for the village in Middlesex?
Again as I understand it, the London-versus-absorbed-village problem is supposed to be solved with time periods, but again, it's not that simple. As I said, the location in FS's indexes has never paid any heed to the notion of "name at the time of the event", and neither do many users of the site. So the search can't just return "all London results dated after absorption", because that'll miss the pre-absorption ones that are nonetheless labeled London.
No, there is no error message for choosing the wrong time period. There are (at least) two reasons for this: one, not everyone follows the at-time-of-event convention, and two, the database doesn't have dates for everything. I think the deficiencies of the database account for at least part of what's been observed about Middlesex-versus-London, too: if entries for a place got into the database from separate sources, they're not necessarily connected to each other, and searching for the one will only turn up the other if there's a variant name in common or similar connecting detail. This may be less common in England — it's all in English and relatively small, so it has been pretty thoroughly cleaned up, over the years — but in exchange, the frequent re-use of English placenames in other parts of the world means that the search/match algorithm's attempts at working around the one deficiency results in it looking like there is no Brighton in England (unless you add the county), or like Islington, Middlesex is a different place than Islington, London.
2 -
It therefore seems clear to me that something in the search process is refusing to equate "Islington, Middlesex, England, United Kingdom" from the input query with "Islington, London, England, United Kingdom" on the files.
I guess that while this goes on (forever?) the answer to my issues above is, quite simply, I have to run a query for each different name of "Islington" - once for "Middlesex", once for "London" and I daren't think what else. That's OK for searches but, to get back to @Paul W 's original query, it almost certainly isn't possible for hints since they are just background processing that cannot have their placenames adjusted.
So - how many people will know to run two queries? (Don't tell me, most of you know this already and I'm just behind the times… 😏 )
But will everyone know to run two queries? Will everyone even know what the other names are - if there are any? It would be good if this was explained to people, especially as needing to do 2 queries (or more) cuts across the "less is more" philosophy.
@Julia Szent-Györgyi - interesting that you believe that the intention is / was that
every location in the database [should] have all of its possible names and jurisdictions connected, so that searching for Islington, Middlesex will turn up anything that took place there, even if it's labeled as Islington, London
It wasn't an idea that I'd come across but it would be really nice.
1 -
My understanding of the motivation behind the whole entities-not-strings decision and the ensuing autostandardization debacle is that they wanted the search to be based on the point on the map, not on its labels. A places database where all the names are connected is a necessary (though not sufficient) part of that.
2 -
@Julia Szent-Györgyi - thanks for that. With Paul's Islington issues, your explanation, and my experiments, it makes sense to me in a way that it didn't do before.
0 -
Thank you for your investigations regarding this problem, Adrian and Julia.
I believe the example below - still involving Islington, but a different surname - illustrates the need for this matter to be escalated, as it illustrates there is obviously something seriously wrong here.
Regardless of location, surely a search for births of an Ivy W* Greenfield should at least have instances of an Ivy Greenfield prioritised in the list of results? Yet, although top of the (48 page) list is an Ivy (Ada) Greenfield, the following result is for a William Maurice Greenfield! Instead on finding instances of Ivy Greenfield prioritised, they are found as far down as page 5, behind the rather less likely return for the 1930 immigration record of a William GRAYFIELD! I gave up at page 20, still not finding any trace of my Ivy W Greenfield birth record.
For an experienced researcher (especially one knowing about the Middlesex / London locations being used interchangeably), the result is far more easy to find. By simply changing the "Middlesex" to "London" my sought-after event comes out top of the list! See https://www.familysearch.org/search/record/results?count=20&q.birthLikeDate.from=1903&q.birthLikeDate.to=1907&q.birthLikePlace=Pancras%2C%20London%2C%20England%2C%20United%20Kingdom&q.givenName=Ivy%20W%2A&q.surname=Greenfield&treeref=GBB6-R8G . Moreover, her marriage event is the second item, even though I'd only completed the Birth Place / Year fields!
Again, with my twelve year's experience in using FamilySearch to find records of my relatives and others, I am quite aware of how to narrow down my results: through the use of "Exact" searches, wildcards, etc. But for the inexperienced user (more familiar, say, with using Find My Past or Ancestry search engines) it must be so easy to fail finding records that should be given much higher priority, based on the inputs made on the Search pages.
@Ashlee C. - would you kindly escalate this issue to the appropriate team, as something is very clearly wrong when a record cannot be found merely because of a different county being inputted as part of the placename - especially when most of the 948 results returned in the first example I have provided are not even for an individual named anything similar to Ivy Greenfield.
0 -
@Paul W Good morning.
On your second search above, I tweaked your parameters ever so slightly—designating a search only for births and for Ivy to be the Principal in the record. Results - 14 records, with Ivy's birth at the top of the list.
Since the Principal option was added last year, I've found it most useful in winnowing out issues of too many non-relevant results.
2 -
Update - I just found a further way of getting the subject of my search to the top of the list. https://www.familysearch.org/search/record/results?count=20&q.birthLikeDate.from=1903&q.birthLikeDate.to=1907&q.birthLikePlace=Pancras%2C%20Middlesex%2C%20London%2CEngland%2C%20United%20Kingdom&q.givenName=Ivy%20W%2A&q.surname=Greenfield&treeref=GBB6-R8G shows that by entering the placename in a totally incorrect format of "Pancras, Middlesex, London,England, United Kingdom" I have no problem!
Anyone who lives in the London area knows it is a case or Middlesex or London that should follow the name of the area / town (according to the relevant time period), but never both together. There is not even a placename (formatted as above) in the FamilySearch Places database.
Not directly relevant to this conversation, but - in spite of that - FamilySearch (and, admittedly, other websites) do have many records recorded exactly in that (incorrect) manner.
1 -
Thank you for that further suggestion on narrowing down results - especially when the method produces a positive outcome!
However, I hope you would agree, there is little direct guidance on making searches that produce optimum results - well, true in Help articles, but not on the main Search page itself (no mention of wildcards, for example, even in the "Tips for effective searches" link), so my main concern is for inexperienced users. Should they honestly expect that this record cannot be found among 948 results, just because of one slight difference in the formatting / inputting of the (county in the) placename?
I would just wish for an investigation of whether this problem has arisen due to a recent change to the "search algorithm", and/or - like another issue that was raised here recently - the engineers believe everything is working correctly and "by design".
2 -
Absolutely agree that better Guides to Searching should be made available for new users. We old-timers have figured out how to make the system give us what we need.
For some of the groups I moderate on other platforms, I created Finding Aids for the group members to use when working with FamilySearch records - especially records restricted to viewing at an AL or FSC.
2
