* Citing English Census

[AdrianBruce]

...

Census returns. England. Aston, Warwickshire. 02 Apr 1911. AARON, Francis, RD 385; PN 18210; ED 21; SN 101. Collection: 1911 England & Wales Census Collection Image. http://www.findmypast.co.uk.

...
The RG 14 is implicit, as the 1911 census has been identified earlier. However; adding it wouldn't hurt. ...

That seems fine - except that I'd really, really, prefer the RG 14 to appear, not least because it gets you in the habit of including the TNA Class as a matter of course. There are instances where the TNA Class is not implicit from the title.

For instance (and you might not be thinking of using these records yet, if ever), FMP put all the First World War Soldiers' Papers into the FMP collection/record set "British Army Service Records". However, there are two TNA Classes in that collection: WO 363, the First World War Service Records 'Burnt Documents', and WO 364, the First World War Pension Claims. WO 364 papers came from the pensions department but the papers are identical in format to the WO 363 papers and literally nobody understands why the papers in WO 364 ended up in the pensions department - other than "it was something to do with pensions..."

If you were looking for the papers belonging to "Fred Bloggs", in FMP you'd look in the single collection/record set "British Army Service Records". But Ancestry made their collections match the two TNA Classes so you have to do two searches if you're just looking for Soldiers' papers there.

So what FMP did was eminently sensible for searching FMP - but if someone wanted to use an FMP citation to find the stuff in Ancestry (because that's the subscription that they have) then they do need the WO 363 or WO 364.

[Gary_G]

Agreed. I was struggling with that bit about the TNA Class.

What do you think about reversing the initial elements to make long or short footnotes sort better sort better, if used as Captions?

Example:

Census returns. England. 1911-04-02. Hertfordshire. Watford. BUTTERFIELD, Herbert E. RG 14; RD 140; PN 7715; ED 17; SN 101. Collection: 1911 Census For England & Wales. http://www.findmypast.co.uk : 8 Mar 2020.

In "pure" Strathclyde style, the bibliography, footnote and short footnote are all the same.
If the above works; I may further tweak things as follows to make things conform a bit better to how one typically sets up a document.

Bibliography
Collection: 1911 Census For England & Wales. http://www.findmypast.co.uk : 8 Mar 2020.

Footnote
Census returns. England. 1911-04-02. Hertfordshire. Watford. BUTTERFIELD, Herbert E. RG 14; RD 140; PN 7715; ED 17; SN 101. Collection: 1911 Census For England & Wales. http://www.findmypast.co.uk : 8 Mar 2020.

Short Footnote
Census returns. England. 1911-04-02. Hertfordshire. Watford. BUTTERFIELD, Herbert E. RG 14; RD 140; PN 7715; ED 17; SN 101.

[AdrianBruce]

... What do you think about reversing the initial elements to make long or short footnotes sort better sort better, if used as Captions? ...

I agree that sort order can be very important but it's one of those things that I am convinced I have used utterly inconsistently in various places...

[fhtess65]

I agree with Adrian - include the RG element as well. While it's true that, using your citation as below, if someone is looking at Ancestry rather than FMP, they can also find the same person (I did it pretty quickly - just put the Schedule Number in Keyword), it's still best practice to include the full reference code for any source, and that includes the Record Group Number. You can just never predict when that information might also been needed.

...

Census returns. England. Aston, Warwickshire. 02 Apr 1911. AARON, Francis, RD 385; PN 18210; ED 21; SN 101. Collection: 1911 England & Wales Census Collection Image. http://www.findmypast.co.uk.

...
The RG 14 is implicit, as the 1911 census has been identified earlier. However; adding it wouldn't hurt. ...

That seems fine - except that I'd really, really, prefer the RG 14 to appear, not least because it gets you in the habit of including the TNA Class as a matter of course. There are instances where the TNA Class is not implicit from the title.
<SNIP>

[trevorrix]

As I am a strict lumper I use Ancestral Sources method 2 for recording census. The vast majority of my research is in England so I simply record places as parish comma space county.

[Gary_G]

Trevor;
My having more countries to cover does pose some unique problems in recording places.

[Gary_G]

In going over the Titles of my Census images, I'm wondering if I should actually avoid using a person's name. If I omit the name, I can store a single copy for the image of each census page, but I'm concerned about losing track of why I saved the image. Is anyone using the Keyword or Notes field to store a searchable list of the people to which an image pertains. That approach might allow me to use a Title that doesn't identify the person.

Also; I've structured my Titles so that all the census records for a particular parish sort together and then by year. This is so that I can more easily find if I already have a sheet that might contain a target area and year. However; there may be reasons to sort in another fashion. As I'm doing all my renaming prior to entering the data into FH7, now is the time to consider alternatives. If anyone has tried what I've outlined and sees some practical issues with it, I'd like to hear about it before proceeding.

Sample of image Titles

Screenshot 2024-03-26 at 4.43.10 PM.png (186.94 KiB) Viewed 396 times

By the way; I'm still struggling with British place-names, so I fully expect that I've made some errors. I'm toying with discarding the idea of using the historical names, because I would like to have things geocode without too much fuss. The rationale I've seen in many books is that using the old place-names allows one to guess at where records might be stored. However; I've not found that to be much help, since records are often re-distributed to various archives over time.

[jelv]

I only have one image for each census page; multiple sources can link to a single image.

On the records media tab, if a select a media item with multiple links then use View, Record links... I can see the sources linked to the image. As each source relates to a single schedule, I include the name of the principle in the full title so I can quickly see why I have an image. I can also select a source and go to the source which has the full list of names in the text from source.

One image - multi sources.png (70.48 KiB) Viewed 390 times

[ADC65]

I'd imagine you are going to get as many variations in answers as there are members of the forums

In going over the Titles of my Census images, I'm wondering if I should actually avoid using a person's name. If I omit the name, I can store a single copy for the image of each census page, but I'm concerned about losing track of why I saved the image.

I would say yes, avoid using a name in the title, for the exact reason you have stated. I know for a fact people will have different opinions on this, but I don't use the 'head of household' as an index to the census entry. Even if you do, it becomes complicated when you have more than one family / head of household on the same sheet - unless you want to have duplicate copies of the same sheet.

I mark or highlight the census image to show who it relates to. It saves searching through some of the messy handwriting on a lot of the images. Some purists don't like this, but I'm not bothered, it's a digital image.

Is anyone using the Keyword or Notes field to store a searchable list of the people to which an image pertains. That approach might allow me to use a Title that doesn't identify the person.

Ancestral Sources will allow full transcriptions to be stored. Have you used those? Definitely worth having a look at if you haven't already.

Also; I've structured my Titles so that all the census records for a particular parish sort together and then by year. This is so that I can more easily find if I already have a sheet that might contain a target area and year. However; there may be reasons to sort in another fashion. As I'm doing all my renaming prior to entering the data into FH7, now is the time to consider alternatives. If anyone has tried what I've outlined and sees some practical issues with it, I'd like to hear about it before proceeding.

I don't see any major issues with your system. I name mine in the order "UK Census YYYY - Country, Town, Address", for example, UK Census 1939 - Wales, Hopkinstown, 60 Telelkebir Road. Note I don't bother with the county in the filename (which matches the source title), at least for the UK. For some reason I do it for the US, I'm not sure why I got into that habit. I also don't put in the source reference in the title as I wouldn't find that useful for me - the Publication Info in the source would hold that (e.g., Class: RG15 / Piece: 26159 / RD: 585 / SD: 4 / ED: 02 / Schd: 028).

By the way; I'm still struggling with British place-names, so I fully expect that I've made some errors. I'm toying with discarding the idea of using the historical names, because I would like to have things geocode without too much fuss. The rationale I've seen in many books is that using the old place-names allows one to guess at where records might be stored. However; I've not found that to be much help, since records are often re-distributed to various archives over time.

You're right in that trying to deduce record archives from a place name is not going to give consistent results. Place names in unfamiliar territories are always prone to error. I would say a lot of mistakes get made about British place names by British people, and trying to decide what county a town should be listed under is not a trivial task for some places that might have changed half a dozen times. So I would pick what suits you best, but just be consistent about it.

[Gary_G]

John and Adrian;

Thank you for taking the time to respond. I see some good points in what you've said. I'll be re-reading your posts to see if I can tease out more ideas.

From your suggestions, I suspect that at least one of you uses Generic Sources and I don't know if you tend to use Method 1 or 2. I should have noted that I use Method 1 (Splitting) and templates. This means that there may be aspects that I can't implement quite as you've suggested.

What still bothers me is that once the images are linked to the database, the title of an image and to whom the image record pertains obviously becomes irrelevant. By that time the database already links all the "pieces" of info together. However; until I have all my existing images fully entered, they still need to somehow identify the person(s) of interest; especially if I remove the names from the titles. This is because I will still need to locate the correct image to link when using A.S. for data entry. That is why I suggested having some method by which I could find the relevant image for a person.

As for location names, I think I'll go with what I can "automatically" geolocate. This is because no reader of my family history is likely to be familiar with historical names of places, but will want to see family groupings on a map.

[ADC65]

Yes, I use Generic Sources and Method 1 (Splitting). I did try Templates but they didn't suit me for a number of reasons which I won't go through here. I do record a lot of source information assiduously and consistently but I don't need templates to do it. I do understand other people's need or desire for them. As you say, there may be some subtle differences that mean you can't implement some ideas, but I'm not aware of them off the top of my head.

I see more clearly now what you are doing - sorting through the images before entering them to FH. That's quite clever while you are trying to sort out which system/method you are going to use. In case you are not aware, Ancestral Sources has the functionality to rename a file when you enter the data, to either a formulaic title, or to a template, or (as I do) rename it to the same as the Source Title it is going to create. It can also place the file in specified directory folders. So I would say that it doesn't matter what you call the image at the moment - it can be renamed automatically when you process the data into FH via AS (which is a workflow I would highly recommend).

[t4ms]

Another Adrian is joining the conversation. Only this one is less knowledgeable, lives Down Under and may not be as handsome.

Greetings, from another Australian

The short answer is that you'll get a bazillion different versions of how people cite census returns. It's whatever floats your boat insofar as (IMHO) whatever you do is 1. consistent and 2. findable (by someone else).

As someone who has been perfecting her own templates since the FH7 rollout I highly recommend (in your case, I did mine from scratch):
Cloning a template that suits to a new collection which you name
Making any necessary adjustments
Playing with that template
Making any necessary adjustments
Rinse and repeat.

Here's an example of a census return citation:
1901 England Census, Washington Hotel, Foxhall Road, Blackpool, Lancashire, England; National Archives (UK), RG 13/3972, Folio 147, Page 20; Household of Geo C Barrett, Lines 6-9.

The bulk is the source and the 'Household, lines' are the citation. The title is RG 13/3972, Folio 147; 1901 England Census, Blackpool, Lancashire, England.

I input census returns by household using the individual census feature with other residents etc as the witness function.

You might find the driver in how you want to cite census returns is in how you manage your census returns.

Tamara

[tatewise]

I've moved the posting by AJSnelson to Essentials Templates Advice (22930) in the Sources, Citations & Repositories forum, which is more appropriate.

[tatewise]

The following may be stating the obvious and many of you may know them:

1. The Media filename does not have to be the same as the Media Record Title.
2. Multiple Media Records can link to the same Media file if required.
3. The Media Record Title does not have to be the same as the Source Record Title.
4. Multiple Source Records can link to the same Media Record, e.g. multiple households on one Census page.
5. A Source Record can link to multiple Media Records, e.g. one household spans two or more Census pages.
6. Historical placenames can be auto-geolocated using the Standardized field in the Place Record.
   i.e. Place field holds the historical placename; Standardized field holds the modern placename.
   Auto-geolocating first tries the Standardized place but if empty uses the Place field.
7. There is no fundamental difference between Generic and Templated Source Records other than the selection of fields available.

[ADC65]

The following may be stating the obvious and many of you may know them:

That's a great summary Mike.

Sometimes when trying to figure out how to approach recording data in FH the 'obvious' becomes obscured and this is an excellent reminder.

[Gary_G]

I slept on the ideas overnight and believe that I can now explain why the issue of how to tag my media files is so important to me.

The big issue is that I keep a LOT more images and data on a person/record than I enter into FH7 (or any program) and so just link to the needed ones in my filesystem. For this reason alone, renaming the original files during data-entry is out of the question. Renaming just one file of a set would completely mess up my filing-system.

I also tend to do my research as a separate activity from data-entry. This allows me to ensure that my research is filed in a program-independent manner. [I learned from TMG that depending on the program to always be around was not a great idea.] Then I only import links to the relevant records into my target program and give them internal names according to what the program allows. I try to use an internal naming structure that allows me to see gaps and patterns in what I've loaded into the program and to find a person's records during the subsequent data-entry phase. The image I posted shows how I've tried to do this for FH7.

So; it looks like my options are limited in the case of FH7. I'll have to have duplicate images, when several people or family groups (for a census) exist on an image. Guess that means that I'll also have to retain people's name info in the Media record title in order to avoid duplicate titles.

[jelv]

I don't see why that means multiple copies of the images. As Mike pointed out above (point 2) you can have multiple media records for the same image.

[Gary_G]

"jellv";
I have a file structure outside FH7 that files more than just images.
The filenames in that file structure are person-based, since some of the filed information needs to be person-based.
This means that I need to follow a similar convention within FH7 in order to be able to relate the two systems.

[tatewise]

Gary, I've lost track of the purpose of your OP.
There you said you wanted to "store a single copy for the image of each census page".
But now it seems you cannot do that because "the filed information needs to be person-based".

[Gary_G]

Mike;

I originally wanted to have just one copy of an image, but I posted the following to explain that perhaps that wasn't possible in my case. I suppose that this is one of the issues with use "threads". It's more difficult to easily see how the original viewpoint has change over the course of the discussion. The following was my attempt to "pin" my current thinking at a more recent point in time.

I slept on the ideas overnight and believe that I can now explain why the issue of how to tag my media files is so important to me.

The big issue is that I keep a LOT more images and data on a person/record than I enter into FH7 (or any program) and so just link to the needed ones in my filesystem. For this reason alone, renaming the original files during data-entry is out of the question. Renaming just one file of a set would completely mess up my filing-system.

I also tend to do my research as a separate activity from data-entry. This allows me to ensure that my research is filed in a program-independent manner. [I learned from TMG that depending on the program to always be around was not a great idea.] Then I only import links to the relevant records into my target program and give them internal names according to what the program allows. I try to use an internal naming structure that allows me to see gaps and patterns in what I've loaded into the program and to find a person's records during the subsequent data-entry phase. The image I posted shows how I've tried to do this for FH7.

So; it looks like my options are limited in the case of FH7. I'll have to have duplicate images, when several people or family groups (for a census) exist on an image. Guess that means that I'll also have to retain people's name info in the Media record title in order to avoid duplicate titles.

[Jean001]

[Off-topic, but following on from later posts.]

I'm am happy to download multiple copies of census images. All my filenames start with the name of the Head of Household, or person of interest. However, if I were conducting a one-place-study I would save one image per page. My rationale is that in the former I am saving information about people, in the latter I would be saving information about a place.

Also, my working method is not conducive to having to check for a pre-existing image file in order to determine whether to download a copy of the current image. For one thing, it would interrupt my flow of thought.

My process is that I carry out a session of research (these days mostly on line) during which I create Source Records and copy and paste to each all available text (e.g. transcriptions, accompanying information and source references). Where an image is available I download this and link it to the Source Record. At times there might be multiple images, e.g. where a household is split over two images. I am a 'splitter' so at the end of a session I might have several dozen new Source Records.

The Source Records replace the notebooks and papers that used to be accumulated during a visit to a Records office, for example. I usually have a backlog of Source Records to link to people.

When I am ready to work on a Source Record I 'tidy up' the downloaded text. If there is an image I transcribe its contents. I organise source references for consistency across my project. Then I enter Facts as appropriate.

I use Generic Sources, entering all information 'manually'.

[tatewise]

Jean, have you considered using AS to streamline that process?

[Gary_G]

Jean;

My workflow and style are similar to yours, except that I use templates (no big difference there, really). I have checked out A.S. and will likely use it. So; I suspect you will also find it helpful.

I would strongly recommend trying it out on a copy of your database, before "going live". This is because it can take a bit of setup and for some images it will result in several facts for different people. Consequently; input errors can take a bit of time to fix. Once you get used to it, the potential for rework goes 'way down.

[Jean001]

Jean, have you considered using AS to streamline that process?

I have indeed, and more than just considered. The first time in my early days of using FH, and then again in 2021.

I have no complaints about AS, it's a brilliant program.

However, I found that by using AS the details of sources did not stick in my mind. I am by nature a person of consistency and detail, and I enjoy the manual aspect. The quirks of my brain!