Fix indexing on "England and Wales, National Index of Wills and Administrations, 1858-1957"
It is clear to me that this collection has been indexed using at least two methodologies. It really needs to be reindexed or the indexes otherwise improved, else people will not be able to find the information that they need
Example 1 (Hannah Mottram) (Screenshot of calendar from "another" website)
Indexed in FS like this:
Method apparently adopted:
Residence Place has been indexed as "Haslington, Crewe" (clearly just as text, not as a place item)
Probate has been indexed as Event Place Original = "Chester" (presumably just as text, not as a place item as it's only one word)
Probate has been indexed as the auto-generated Event Place "Cheshire, England, United Kingdom."
Comments - This is a good index record in my view, the only oddity is why the auto-generated Event Place isn't "Chester, Cheshire, England, United Kingdom" because that's surely what Event Place Original should generate. Isn't it?
Example 2 William Edward Parton
Indexed in FS like this:
Method apparently adopted:
Residence Place has been ignored as a separate item. Instead, it has been merged in with Probate.
Probate has been merged with Residence and indexed as Event Place Original = "Chester, Crewe, United Kingdom" (presumably just as text, not as a place item as there is absolutely no such place. Unless you know better.)
Combined Probate and Residence has been indexed as the auto-generated Event Place "Crewe by Farndon, Cheshire, England, United Kingdom."
Comments -
Residence has been handled totally differently in this record compared to the first.
This record, therefore, is missing an index value compared to the first.
Probate has been merged with Residence - in my view, this should never happen if the combined item is going forward to be turned into a Place. It might be permissible if the item were to remain as a single text field, rather than be turned into a place-name field. As it is, note that Crewe and Chester are wholly different places.
The auto-generated Event Place is just plain wrong by any standards. Crewe by Farndon exists but it is on the other side of the county from the Crewe in this example. Nor is it near Chester. I have no idea how the auto-generation has come up with that value but starting from the non-existent "Chester, Crewe" is a bad place to start from.
Overall comments
We have mentioned this before - the Beneficiaries indexed are not Beneficiaries - they are the executors. That is, after all, what the original calendar entry says - "Probate to ..."
Please alter Beneficiaries to Executors.
Please ensure this collection is indexed consistently throughout.
Please do not merge Probate and Residence.
Suggest you leave Residence as a text item and do not try to turn it into a place-name as there may not be sufficient data to specify a full place-name - a lot goes by context.
Answers
-
I wonder if the citation details give a clue as to whether separate projects are involved here. Otherwise, maybe project instructions got changed part way through the exercise! As you know, more recent wills are indexed in a different manner, but the two examples that you illustrate are for items only a couple of years apart and of exactly the same format.
The nearest comparison to this with England & Wales records (albeit not a very good one) is with the different sources used for death records. Some appear to compare directly to the GRO ones, but others have postcode detail, which presumably means their source relates to the locally held record. But I wouldn't think that one of the above records relates to a record held at Chester and the other for the copy held in London.
From the reaction to other requests to completely index a set of records, I would think that is probably wishful thinking that FamilySearch will go so far. It's perfectly reasonable to request this, of course, but as you mention in your comments, the Beneficiaries v Executors issue has still remained untouched, in spite of FamilySearch being made aware of this error in terminology several years ago, and this should have been very straightforward to fix.
2 -
"I wonder if the citation details give a clue as to if separate projects are involved here."
Interesting thought... Example 1 is on https://www.familysearch.org/ark:/61903/1:1:W5LR-NFT2 and has a citation (obtained by using the "Copy Citation" button):
"England and Wales, National Index of Wills and Administrations, 1858-1957," database, FamilySearch (https://www.familysearch.org/ark:/61903/1:1:W5LR-NFT2 : 2 September 2022), Hannah Mottram, 11 Jan 1929; citing Probate, Cheshire, England, United Kingdom, Her Majesty's Stationery Office, Great Britain.; FHL microfilm .
Example 2 is on https://www.familysearch.org/ark:/61903/1:1:7X3T-GYT2 and has a citation:
"England and Wales, National Index of Wills and Administrations, 1858-1957," database, FamilySearch (https://familysearch.org/ark:/61903/1:1:7X3T-GYT2 : 27 August 2019), William Edward Parton, 10 Nov 1931; citing Probate, Crewe by Farndon, Cheshire, England, United Kingdom, Her Majesty's Stationery Office, Great Britain.; FHL microfilm .
I hadn't noticed the absence of an "FHL microfilm" number in both cases - makes it look incomplete. Oddly the URLs differ in that one contains "www" and the other doesn't. I assume this doesn't matter. Apart from that I can't see any hint that two or more projects were involved.
Do I expect the records to be re-indexed? No, not really. But I feel it's important to state what should happen in a perfect world. Plus, if the rules did change, then the question is why? Maybe they only realised "Residence" was present partway through so Example 2 was indexed under the old rules, and Example 1 under the new - with a separate Residence. In which case, the important thing is not fixing this collection but stopping the same issue from occurring again. In particular, why wasn't the data examined closely enough, all the way through, before writing the indexing rules?
1