Source Linker for 1920 U.S. Federal Census Dropping Locality Data in Event Location

Brad Felmey

I want to make clear up front that this is not about the broader issue with source linking right now.

For at least some localities in the 1920 U.S. Federal Census, the source linker page is failing to include the locality in the functionality to add a residential timeline entry, even though the data is clearly still in the index itself. I have not observed this behavior in any other census.

As an example, about five years ago I attached the 1920 census to my 2x great-uncle (FS ID L8T6-F9K). The format of the source when added to his "Other Information" took this form:

Bridgeton Ward 3, Cumberland, New Jersey, United States

A while back this behavior changed for this specific census, in that when source linking is performed, the locality data is not included in the event place, i.e.:

Cumberland, New Jersey, United States

It's easy to see that the locality data IS still in the index by selecting the source image and looking at the header:

This omission is also observed when I navigate to the Sources tab and expand the 1920 census as currently working compared to, say, the 1910 one. Note the Event Place values.

1920:

Compared to 1910:

Let me be clear that the 1920 census DID have the locality data included in the event data once upon a time, but now no longer does. I consider this therefore a defect I'm reporting. I'm not sure how broadly this issue affects the 1920 U.S. Federal Census, but I can report that it affects a great deal of the northeastern records with which I work.

Julia Szent-Györgyi

I think this actually has nothing whatsoever to do with the Source Linker: it is a result of the autostandardization process, with apparently an intermediate step that lost specificity in the 1920 census.

You can recognize the recent autocorruption ::ahem, sorry:: autostandardization process by the presence of two location fields, one labeled with a parenthetical "original". Usually, the text in that "(original)" field is what was either typed by an indexer, or added by a pre- or post-processing step based on the film cataloging data. (The latter is by far the more common, in my observation: locations that apply to entire pages are not typically typed by indexers.) I don't know what happened to the 1920 census index that removed the previously-complete location information from this field; perhaps it was a preliminary attempt at transitioning to entity-based location searches?

(The reason for the autostandardization mess is that FS decided to do away with text-string-based searching in date and location fields. Instead, dates and places are now associated with standardized database entities, and your search terms are matched to an entity. Such matching is much more efficient than text-based searching. However, the problem is that the database associations were entrusted to automated routines, with apparently zero data validation or other sanity checks. Needless to say, the bots Got It Very Wrong, and are continuing to Get It Wrong, with the end result that you can't trust anything that Search - Records says about "where", and it's pointless to use the place fields in searches.)

Brad Felmey

https://community.familysearch.org/en/discussion/comment/460287#Comment_460287

Thanks - that's a very helpful and plausible scenario.

And LOL at "autocorruption". :D :D :D

CESchultz

This is a also a problem with 1870 Census Record.

Brad Felmey

https://community.familysearch.org/en/discussion/comment/460602#Comment_460602

Yes, in some localities. I have seen this corrected, at least in the localities I typically work in Southern New Jersey.