1881 Canada Census - Ontario
Noticed that all of 1881 Census in Ontario has been totally mixed up. Will this be either put back the way it was or fixed?
Answers
-
Every record in the 1881 Census for Huron County has changed the "Event Place" from correct assignments to incorrect, regardless of the contents of "Event Place (Original)". What can be done to fix this problem? When I search on Huron, Ontario, Canada it appears that all 1.9 million census records return (ie all of Ontario). Maybe these are 2 different issues, but new in the past few weeks. ARGH!
0 -
@N Tychonievich, please and thank you. Placename algorithm again. URL: https://www.familysearch.org/ark:/61903/1:1:MVN9-YSB
0 -
mod note - two discussions were merged here and duplication from the two were removed.
1 -
As Áine alluded to, there is no indexing error here -- the field labeled "(Original)" is what was indexed, and as you noted, it's correct -- but I haven't been able to figure out the cause or origin of the "list of places" error. Is it a new chapter in the ongoing autostandardization mess? Or is it a creative way that the new edit-everything index-correction tool has come up with to cause errors? Or, perhaps actually most likely, is it a combination of those two things that's wreaking havoc?
2 -
@Julia Szent-Györgyi - re the "list of places". There is a pointy-up arrow or pointy-down arrow to the right of the "Event Place". When there is only one item in the list for "Event Place", it's the pointy-down arrow by the side and the tooltip for that arrow, when you hover over it, says "Expand Edit History".
If you click on that arrow, it swaps to the pointy-up version and the list of places seen in the screenshot appears. The tooltip then says "Collapse Edit History".
If you are going to ask me what the Edit History bit means - especially given that "Event Place" is auto-generated (or it was as far as I knew) - then I don't know. Not the faintest. It may, as you suggest, be something to do with the Edit Everything but I've no idea how.
I tried to find the same source record in the Beta site but it doesn't actually look like it's the same...
0 -
@Adrian Bruce1, oh, I know about the edit history arrow. Or what's supposed to be the edit history arrow. Only, when it lists the entire drop-down list (or sometimes, what seems like half the places database) like this, it's not actually an edit history. Nobody added all of those places to all of those entries. It's some other process hijacking that "slot" -- and the most likely candidate for that process is, as I said, some weird cross between the autostandardizer (or the process trying to clean up after it) and the new index editor.
(Sources basically don't work in Beta, in my experience. I think index entries don't actually have beta versions.)
2 -
I am not sure of correct terminology but when I say an indexing error, I am referring to the fact that when I go to attach the record, in the case above, it indicates the person’s residence is in Lambton County, not Huron County. And if I were to add that info without viewing original source and manually changing their residence to match the source, it would be incorrect, it was fine before… There are around 78,000 census records in Huron County in 1881 not 1.9 Million. Why are 1.9 million records returning on a search for Huron County, Ontario? These errors are new, ie in the past few weeks I have noticed. Hoping it can be fixed. I assume this issue is for all 1881 census records in Ontario Canada?
0 -
Example only - All the 1881 census records have this error, the correct place is gone replaced by some random location…
0 -
As Julia explained, it's not an indexing error. The "original" shows what was indexed; that was correct. Then the computer algorithm for placename standardization changed the correct placename to, apparently, the first place it found with a similar name. N Tychonievich has taken the lead in shepherding these errors to eventual correction.
2 -
I suppose it's somewhat nitpicky or pedantic when we object to calling it an indexing error, because the index is unquestionably (now) wrong, but it's a question of implied blame: an indexing error means an indexer did it wrong. Now, it's a fact of life that indexers do do it wrong, quite frequently, but not in this case. These errors were caused well after the indexers finished their task. They're index errors, not indexing errors. (As I said, pedantic and nitpicky, but I think it matters, not least because it'll point the troubleshooters closer to the correct direction, whatever that is.)
2 -
@Julia Szent-Györgyi said:
" .. I know about the edit history arrow. Or what's supposed to be the edit history arrow. Only, when it lists the entire drop-down list (or sometimes, what seems like half the places database) like this, it's not actually an edit history ..."
Oh - now I'm embarrassed about telling you something you already knew. 😕 In my defence, I didn't notice any reference to the arrows and I'd not immediately realised that clicking it would swap between 1 entry and the list, so when I did discover it, I thought it important to say so.
Yes, I can't work out what that list might be for either - that's why I tried to see what the situation was in Beta - no chance. Perhaps a facility has been implemented but someone hasn't yet told us about that facility? Or maybe we're only halfway through implementation?
I can't even reverse engineer any logic about what "edit everything" might mean if you're allowing editing of a field which is normally completed by the auto-standardisation 'bot. What would be the point of allowing such an edit if the 'bot runs again later on and recreates the incorrect choice? No idea so, like you, I'm puzzled...
0 -
Thank you for your kind explanations. I am totally new to this forum and only joined due to the frustration with the noted problems which I am sure a person (ie indexer) didn’t do, especially in the past couple of weeks, to thousands of census records. I assume it is some sort of automated process or algorithm as discussed above. But not sure if these processes are working as intended when perfectly fine data is corrupted and then added to a huge backlog lol. Thanks again for passing along.
0 -
You may be new to the forum @Lori9999 but I'm impressed that you've got the hang not just of adding screen-shots but of annotating them as well! 👍️
2 -
@Lori9999 Your frustration is shared. No, the placename algorithm is not working as we would wish. You'll see dozens - maybe hundreds - of threads where we have all been reporting the issues. I'm sure that N Tychonievich's spreadsheet will shortly crash from the weight of so many reports.
3
