* Trying to import Census Reference info for use in FTAnalyzer

[tatewise]

Sorry to be fussy, but all the 1841 to 1911 Census Publication Info fields start with HO or RG.
So would it be more consistent if 1921 started RG15 without the Archive series: prefix
and that 1939 started RG101 without the Source Reference: prefix?
e.g.
RG14, Piece: 83631, Schedule number: 581
RG15, Piece: 26361, Schedule number: 267, Schedule type: W, Page 12
RG101/5088B, Line Number: 31, Schedule Number: 38, Sub Schedule Number: 1, Enumeration District: ODBF

The plugin script is largely the same for every census year. Only a set of conversion templates differ for each year.
So it is easier to convert all the ho/rg anomalies to capitals and no space rather than make 1861 a special case.
It is also easier if every Publication Info field starts with HO, ho, RG, rg, etc, and has no prefix as suggested above.

What do you think?

[David Potter]

Hi Mike

Sorry to be fussy, but all the 1841 to 1911 Census Publication Info fields start with HO or RG.
So would it be more consistent if 1921 started RG15 without the Archive series: prefix
and that 1939 started RG101 without the Source Reference: prefix?

Mike that makes absolute sense to me, thank you for bringing it up.

The plugin script is largely the same for every census year. Only a set of conversion templates differ for each year.
So it is easier to convert all the ho/rg anomalies to capitals and no space rather than make 1861 a special case.
It is also easier if every Publication Info field starts with HO, ho, RG, rg, etc, and has no prefix as suggested above.

Again, this makes sense to me, if I have a choice I would prefer all Capitals and no Lower case. Having checked a lot of Census references lately for Findmypast, Ancestry and Lost Cousins they all seem to favour Capitals in the Class part. Eg, HO or RG.

Thank you Mike

[tatewise]

OK, try the Copy Census Source Reference to Publication Info plugin Version 0.5 Date 31 Jan 2024.
( This is the new link via OneDrive method instead of Attachments. )

I have not tested any of the new census years recently added as I don't have spare time to create ORA Note text.

So I'll leave it to you to test all the years exhaustively.

What I have done is make the templates that match each ORA Note more tolerant of misspelt words.

[David Potter]

Hi Mike. Thank you very much. I'll test thoroughly starting tomorrow afternoon now as I'm off to bed now.

I have downloaded the Plug-In and installed okay.

[AdrianBruce]

Just to let my inner pedant off the leash a little...

Strictly speaking the references at TNA have a space between the letters (Department Code) and numbers (Series Number) of the class. So it's actually "RG 15" with a space in the middle, not "RG15".

I don't think it matters at all here, in fact, it might be very wrong to enter the space in this context? But certainly, it used to matter down at Kew where I remember entering references that found nothing even though I'd just copied them off the screen seconds before. Of course, I hadn't copied them accurately because I'd omitted the space.

I note, however, that the online TNA Discovery Catalogue seems to accept spaceless references and match them with spaced references. Quite sensibly.

[tatewise]

That may well be true Adrian, but the online records mostly seem to omit the space.
e.g. Ancestry, FindMyPast, Lost Cousins, etc.

[David Potter]

Thank you Mike. Sorry only just able to reply. But you have done that already.

[AdrianBruce]

That may well be true Adrian, but the online records mostly seem to omit the space.
e.g. Ancestry, FindMyPast, Lost Cousins, etc.

Indeed - and, as I said, it seems not to matter for TNA's Discovery Catalogue these days. Hence loads of people haven't learnt that there ought to be a space there. ("Ought to", not "must")

As an aside, the TNA references aren't the only ones to cause problems - I think the space-or-not issue affects other catalogues, while Ancestry's attempts citing the Manchester Record Office references are a veritable PITA because they seem to need ... something ... as a prefix. It doesn't help that MRO's Catalogue software is weirdly different from others.

Reference formats are something that I think we ought to be wary of when citing our sources.

[David Potter]

Hi Mike, All tested okay.
I had some issues with Census records where there are vessels involved, as in fishing vessels. The Page Number is not used for those records. So I manually tweaked the result to add Page: 1 which appears to be the expected value; although not present in the reference data that ORA captures, or indeed not referenced on the usual suspects as FMP and Ancestry.

Thank you so much for your efforts here. Very pleased.

[Mark1834]

Picking up Adrian's point, it's interesting to see that National Archives themselves haven't been fully consistent. Up until around 1881, many images are shown with H.O. or R.G. rather than RG, reflecting the now old-fashioned style of including full stops with initials. 1891 lost both the space and the full stops (RG12), but 1901 reinstated the space (RG 13).

I record all my citations consistently with no full stops or spaces, irrespective of census year. It fits my main requirement of "necessary and sufficient" to describe the source unambiguously, even if it's not strictly "correct".

[fhtess65]

I have often found errors in the Ancestry citations for various record offices and archives - I've learned now to ALWAYS double check with the original repository.

<SNIP>
As an aside, the TNA references aren't the only ones to cause problems - I think the space-or-not issue affects other catalogues, while Ancestry's attempts citing the Manchester Record Office references are a veritable PITA because they seem to need ... something ... as a prefix. It doesn't help that MRO's Catalogue software is weirdly different from others.

Reference formats are something that I think we ought to be wary of when citing our sources.

[Mark1834]

Sound advice - I’ve seen too many examples that confuse the original source with an online reference to that source by Ancestry, FMP, etc. They are not the same thing.

[AdrianBruce]

I have often found errors in the Ancestry citations for various record offices and archives - I've learned now to ALWAYS double check with the original repository.
...

Oh good - it's not just me then.

[tatewise]

IMO this is in danger of straying far from the scope of the OP which has been satisfactorily resolved.
If this continues I'm tempted to split it off into the Research forum.