Census image layer

Hello, Mike Bartholomew:

I’m puzzled as to why you see a difference 1950, 1940, and the censuses that came before it. All use the same basic pattern:

You state that, as a matter of policy,

• You set up all [your] citations "based on the published guide to citing records from NARA."
• As more digital records became available, [you] continued … using the same guide.

I have to ask here, two questions:

• Which guide? NARA's age-old guide that has always cited censuses as, say, "Twelfth Census of the United States ..." rather than "1900 U.S. census ..."? Or an earlier edition of EE?
• What access to the censuses did you use when you set up your personal format? (A format standardized for censuses used on microfilm at libraries would not be adequate for censuses used as digital images, without adaptations.)

As a review of core principles, which some readers of this thread made need to more-clearly understand our discussion: 

• We identify records according to their creator and their type.
• We cite access according to how we access the record.

Thus:

• If we access the original, we cite the original and its repository.
• If we access an image via published microfilm, we cite the microfilm for the access.
• If we access an image online, then we cite the online provider in our access layer; if the online image is made from microfilm, it can be helpful to identify the microfilm from which it was produced.
• If we access an image that an online provider has made directly from the originals, then we cite the online provider and, if possible and when appropriate, say where those originals are.

When citing an online provider

• Whether we cite an exact URL or cite to the collection level followed by path > waypoints > image number depends upon the structure of the website.
• EE4 §2.35 provides a general discussion for all record types.  EE4’s §7.10 provides a foundation for all types of census records. Then 7.18, 7.35, 7.37, 7.38 and 7.49 address the issue in the context of variously structured censuses.

You ask: Is there a reason that the second layer in all these examples does not show more details to find the actual image? What additional detail would you propose for the access layer? For online images of census records, EE 4 suggests:

• Layer 1 (the record layer): Citing the census and full details to locate a specific name or household on the census.
• Layer 2 (the access layer): Citing the “Census Collection,” Online Provider (URL for the collection's home page that has a search box).

If, by “additional detail, you mean exact URL or path > waypoints > image number, you can always add that if you wish. However, there are two considerations:

1. If we have fully cited the census itself in Layer 1, then from the collection’s landing page and its search box we can locate the household without an exact URL or path > waypoints > image number.  Using both is considered redundant by those who detest long citations. It can be an added convenience when we need to relocate the document—as in your 1940 instance.
2. Citing to exact URL works best when we are working within word-processing software, as when creating a research report (to our own files or to a client) or a manuscript of a planned article or book. If we maintain our research notes in a relational database and we cite an exact URL, then we will almost certainly have to create a separate source entry note for each URL. Citing to the collection level allows the software’s citation mechanism to replicate itself with each new household we use from a specific census.  (Caveat: the structure of relational databases do differ just as widely as website structures do; I’m speaking here in general terms.)

You also state that, when following EE4’s example for the 1940 census, you had to “do a little sleuthing” to find the right image.  When I retraced the steps to locate that census just now, at the cited website, I noticed two issues. Either of them may have triggered your need for more “sleuthing.”

Locale Name

• When I entered the locale, if I began with “Arecibo,” then FamilySearch gave me a standardized place name to click: “Arecibo, Puerto Rico.”  That led to a list of individuals named Ramón Díaz combined with other forenames. It also identified those individuals by their family members, not by enumeration district or page. The list was a long one to slog through.
• When I entered the locale in the query box, beginning with the barrio (the smallest element of the place) and typed “Factor,” then FamilySearch gave me the option for all men of that and similar names in “Factor, Arecibo, Puerto Rico.” That was, logically, quicker.

Personal Name

EE4 7.27’s editing process created a problem with the name of the person. This census uses the traditional Spanish practice of double surnames—first the father’s surname, then the mother’s surname (without the connector "y" between the two surnames as in some times and places). Each census entry begins with the surname and ends with the given name. This entry, as written on the census, is Díaz Román Ramón. The sample footnote should have rendered it as Ramón Díaz Rámon, rather than Román Ramón Diaz.  You have our apologies and a promise that it will be corrected when EE4 is next reprinted.

With this problem, you also make the case why redundancy can be helpful—citing the exact URL, or path for the exact image, rather than the collection’s search page—if we are not constricted by relational database software.