* How to check missing censuses if Residence used instead of Census.

[jimlad68]

I have been combining Residence facts and their sources for the same Place/Address to a "date range" as a "seeing the wood from the trees" exercise. The logical next step would be to use a Residence Fact instead of Census, the source would still be a Census. I know there are the arguments as to whether a Census is an Event or Somewhere one Resided for that night and indeed Ancestral Sources gives the options for Census, Residence or both.

But, how would I be able to automatically check which censuses are missing. To my mind the Census is a source, and having a list of missing Censuses an aid to research. I have experimented with plugin LOOKUP MISSING CENSUS FACTS which as expected shows the converted "Census to Residence" as a missing census.

The only "practical" option I can think of is to Keep the Census Facts (or duplicate with a Residence), but incorporate their dates into any Residence "date ranges" including the census as a Source.

[tatewise]

As you have discovered, eliminating Census Events in favour of Residence facts has serious side effects as explained in the FHUG Knowledge Base advice Recording from a Census Record.

So your best option is to incorporate the 'residence' shown in a Census into your Residence fact date ranges.
That gives you the option of disregarding temporary addresses shown in Census records that are not the 'normal residence'.

[AdrianBruce]

...
The only "practical" option I can think of is to Keep the Census Facts (or duplicate with a Residence), but incorporate their dates into any Residence "date ranges" including the census as a Source.

Whether by luck or by judgment, I also have used the duplicate case right from the beginning - individual census events on a person by person, census by census basis; and the residence events that usually end up as a range where it's the same Place & Address. Census source records are cited against both those (and many more besides).

I also tend to use date ranges for occupations, again with the objective of helping me "see the wood for the trees". (Not a phrase that it had occurred to me to use beforehand, but nicely appropriate).

[davidf]

I am a little uneasy about trying to express a date range for items such as residence or occupation - you can miss an important tree.

I also tend to use date ranges for occupations, again with the objective of helping me "see the wood for the trees". (Not a phrase that it had occurred to me to use beforehand, but nicely appropriate).

Suppose someone is in:
the 1911 Census as "27 Cromwell Road, Hove", with occupation "Barrister"
the 1921 Census as "27 Cromwell Road, Hove", with occupation "Barrister"
Could you apply a date range and state from sometime before 2 April 1911 to sometime after 19 June 1921, his residence was "27 Cromwell Road, Hove", and his occupation was "Barrister"?

Just looking at census records and in the absence of other records, that would be the temptation.
But if we found some military records, would an occupation of "driver" and a "residence" of "Baghdad, Mesopotamia" between say 1914 and 1918 alter that statement?

We only really know a person's occupation and residence at a point in time (when a record is formed - unless the record reliably and explicitly says "between 1911 and 1921 ...").

Perhaps "occupation" is a calling (in which case in the example above, the individual might argue that his occupation was "Barrister" through-out the period) - but I feel "occupation" is less grand, something that occupies your time, and our individual was occupied as a "driver" according to records for 1914-1918.

Likewise might he have thought of his residence throughout that time as "his home" - which was 27 Cromwell Road, Hove, or is residence just the place where he happened to be residing - and he may have been "in camp" at Baghdad for a "considerable time"?

[Mark1834]

It’s important to distinguish between facts (data) and interpretation (hypothesis). I record facts as supported by sources, so to take David’s example, all we know for sure is that he was listed at the same address on two separate dates ten years apart. If I interpret that as continuous residence, that’s narrative interpretation and I don’t change the time period of recorded facts to fit my interpretation.

[jimlad68]

Many thanks for all those observations.

I am fully aware of the issues of a date range for a place (or other facts) which might not be continuous and in reality one can only say they were there on certain dates. But practicalities and "seeing the wood from the trees" is also important to get a good "feel" for the situation/person. As ever, the important thing is to attach Sources and add comments to the Fact Note.

Indeed during WW2 my newlywed parents shuffled between 3 addresses, added to that my father was posted to different places. I could add tens of Residence Facts for the info I have which would be difficult to make sense of, so my solution is to have overlapping date range Residence Facts with the relevant Sources, The residence note would give known dates and reference to the other overlapping Residence Facts. I did consider that having many Residence Facts could show an "itinerary", but unless you are sure of all of them (say a diary), that too would be likely inaccurate.

As regards my original query of the practicality of using Residence Fact instead of Census I think I will keep with "Keep the Census Facts, but incorporate their dates into any Residence "date ranges" including the census as a Source". This keeps all the detail without too much duplication and the Census facts for easier management of missing censuses.

As an aside, I cannot understand why Residence is an Attribute. What would the {value} be?

[tatewise]

Residence is an Attribute because GEDCOM says so and it defines something that can be associated with a person over a period of time (just like an Occupation or Physical Description). Whereas, an Event can only happen to a person within a very short time frame of a day or so.

Strictly speaking, Attributes can use Date Periods FROM/TO and Events can use Date Ranges BET/AND but not vice versa.

Residence is an exception and has no associated value, unlike all other Attributes.

[jimlad68]

This then begs the question: Is there a quick way to merge Facts? At present I have to manually copy dates and sources and any notes.

Looks like editing the Gedcom file might be quickest and even easiest, but of course more dodgy!

[davidf]

As an aside, I cannot understand why Residence is an Attribute. What would the {value} be?

Where there are two or more residences (attribute value in bold)?
Charles Arthur Philip George Mountbatten-Windsor resided at:

• Buckingham Palace - Official Week-day residence
• Clarence House - Preferred Week-day residence
• Windsor Castle - Official Week-end residence
• Highgrove House - Preferred Week-end residence

[tatewise]

Jim, I'm not entirely sure what facts you need to merge.
I thought you were just extending the Date Period (not the Date Range) of one Residence fact and copying the Source Citation from the Census Event.

[tatewise]

David, perhaps they are not so much Residence attribute values as Residence (RESI.TYPE) Descriptors

[jimlad68]

Jim, I'm not entirely sure what facts you need to merge.
I thought you were just extending the Date Period (not the Date Range) of one Residence fact and copying the Source Citation from the Census Event.

I have existing multiple Residence Facts for the same place, this could be from various Sources or be automatically generated via AS (e.g. a parent in Baptisms). In my plan I would not be merging Census Facts, that would have to be manual addition of Source and possibly date to the Residence Fact.

It is just that I have noticed merging manually it is easy to get mixed up going backwards and forwards. I just noticed via the Gedcom file it seemed easier to see the whole picture. I think I will have to get a better workflow, perhaps a small report that I can check I have merged everything!

[tatewise]

So to summarise, the 'merge' is not a strict merge but more of an amalgamation.
i.e. Multiple Residence facts that have the same Place/Address but various Dates, Ages, Notes and Source Citations need to be reduced to one Residence fact with a FROM first Date TO last Date, discard Ages, merge the Notes chronologically, and add all the Source Citations without duplication.

[davidf]

An hour and a half later, so where's the plug-in?

[AdrianBruce]

It’s important to distinguish between facts (data) and interpretation (hypothesis). I record facts as supported by sources, so to take David’s example, all we know for sure is that he was listed at the same address on two separate dates ten years apart. If I interpret that as continuous residence, that’s narrative interpretation and I don’t change the time period of recorded facts to fit my interpretation.

Fair enough - for me, the Family Historian "facts" are my narrative interpretation. That's simply the way I work and I know that others work differently. I'd only just put my tongue slightly in my cheek and say that deciding that it's the same person at the same address on two dates is also a matter of interpretation. It's partly a question of how much risk we are willing to deal with as to whether we take the reasonable interpretation that it's the same person.

[jimlad68]

So to summarise, the 'merge' is not a strict merge but more of an amalgamation.
i.e. Multiple Residence facts that have the same Place/Address but various Dates, Ages, Notes and Source Citations need to be reduced to one Residence fact with a FROM first Date TO last Date, discard Ages, merge the Notes chronologically, and add all the Source Citations without duplication.

Yes that sums it up nicely, except it would be advisable to have the original dates included in the Note, ahead of the relevant Note(s) if there were any. I suppose an extension of that would be to do it with other selected Facts too (e.g. Occupation), even amalgamate different or a collection of facts, perhaps leaving the date empty, but in the note. One would expect to check and tidy up any result.

In the meantime I have been experimenting and tried "Merge" Files (exporting the individual), but that does not seem to allow any amalgamations of Facts, and would probably be more trouble than it is worth.

[AdrianBruce]

... As an aside, I cannot understand why Residence is an Attribute. What would the {value} be?

You're not supposed to ask sensible questions like that! Warning - IT analysis follows...

The {value} of Residence is the Address and Place - except, of course, they're already elsewhere in the GEDCOM data, so it doesn't need a separate {value}.

The argument that Attributes have values while Events don't, is actually an over-simplification if if if you want to apply logic to it (as distinct from reading the GEDCOM Specification). The argument is that in logic / the English language, an Attribute describes an ongoing status quo, while Events describe the change from one status quo to another.

So a Residence is an Attribute because it describes the ongoing status quo of living at (say) "23 Railway Cuttings, East Cheam". That could be bracketed by Events such as HouseMove or Death or Hospitalisation. Naturally, there is little point for recording some of those events - two adjacent Residences need not be separated by an explicit HouseMove events because it's obvious that it took place. Unless there's a note denying it...

And of course, some Events (in the sense of changes of status) should have optional values - like (the custom event) Inheritance, say...

IT Analysis off....

[AdrianBruce]

I am a little uneasy about trying to express a date range for items such as residence or occupation - you can miss an important tree.
...

Yes, I do try to be thoughtful - I tend not to use a Date Range for an Occupation of Ag Lab, simply because an intervening source might describe him as a "Labourer" rather than "Ag Lab". Not to mention the tendency of parish priests to refer to any unskilled or semi-skilled job as "Labourer" regardless of what it actually was.

...
Suppose someone is in:
the 1911 Census as "27 Cromwell Road, Hove", with occupation "Barrister"
the 1921 Census as "27 Cromwell Road, Hove", with occupation "Barrister"
Could you apply a date range and state from sometime before 2 April 1911 to sometime after 19 June 1921, his residence was "27 Cromwell Road, Hove", and his occupation was "Barrister"?

Just looking at census records and in the absence of other records, that would be the temptation.
But if we found some military records, would an occupation of "driver" and a "residence" of "Baghdad, Mesopotamia" between say 1914 and 1918 alter that statement?
...

I would assign Barrister and 27 Cromwell Road to date ranges 1911 to 1921 with a clear conscience (though the exact words associated with the date ranges are debatable). Primarily I do this because I don't regard a temporary army billet as a Residence, and he's still a qualified Barrister over that time period. (Indeed my grandfather was still on the books of Crewe Loco Works as a fitter throughout his time in the artillery during WW1. Theoretically, he even got pay rises during that time, like any other apprentice - these are documented on his employment record, so they're only theoretical in the sense that the LNW Railway wasn't actually paying him.)

Again, the above is an interpretation of sources, but (a) that's how I work and (b) where necessary, I would add clarifications - or confusions - to the notes against the Attributes in question, such as explaining that he was genuinely still employed by the railway while he was in the Army.

[tatewise]

On a point of order...
There have been several references to Attributes such as Residence and Occupation having a Date Range.
They do not. They have a Date Period (FROM/TO), i.e. the period of time for which the Attribute applied.

Events may have a Date Range (BET/AND), i.e. the range of dates between which the Event happened.

[davidf]

There have been several references to Attributes such as Residence and Occupation having a Date Range.
They do not. They have a Date Period (FROM/TO), i.e. the period of time for which the Attribute applied.

Events may have a Date Range (BET/AND), i.e. the range of dates between which the Event happened.

I'm not sure that I follow - FH V6 allows me to use both

Use of Date Ranges and Date Periods Events and Attibutes

Screenshot from 2022-11-27 14-23-04.png (5.71 KiB) Viewed 2230 times

I can see that it might be illogical to say he was born from 24/12/1891 to 25/12/1891 (although it might have been a long labour); however it is logical to say that a Marriage lasted from 1920 to 1940. If you counter that that is referring to the state of "being married" and is more properly an attribute, I would ask about weddings that last several days (from - to) - do you just enter the date when the vows were concluded?

From and To to me have some definitiveness about them
Between and And indicate that what we are talking about happened / was true sometime between those dates - we don't know any better to be more certain.
And that can surely happen with Events and Attributes?

[tatewise]

FH V6 allows me to use both

True, but FH does not always strictly follow the GEDCOM suggestions.
It is also possible to construct exceptions to most general rules.

I can see that it might be illogical to say he was born from 24/12/1891 to 25/12/1891 (although it might have been a long labour);

But the period of labour is not the birth event, which is usually very quick.

however it is logical to say that a Marriage lasted from 1920 to 1940. If you counter that that is referring to the state of "being married" and is more properly an attribute, I would ask about weddings that last several days (from - to) - do you just enter the date when the vows were concluded?

You have answered your own point by differentiating the Marriage Event (a standard GEDCOM fact) from a custom Married Attribute. There must be an instance in time when a couple legally change from being two single people to being a married couple because there are legal consequences. A marriage certificate only has one date. That change of state cannot last days and is the Date of the Event even if the celebration lasts days. So that may need a BET/AND date if not sure when during the celebration the state change occurred.

From and To to me have some definitiveness about them
Between and And indicate that what we are talking about happened / was true sometime between those dates - we don't know any better to be more certain.
And that can surely happen with Events and Attributes?

As I said, it is possible to contrive exceptions to rules, so yes an Attribute might only apply at some date between a range of dates, but would be unusual.

In the context of this thread discussing Residence and Occupation the references to Date Range were clearly a mistake and should have been Date Period. So I stand by what I said.

[AdrianBruce]

... In the context of this thread discussing Residence and Occupation the references to Date Range were clearly a mistake and should have been Date Period. So I stand by what I said.

I'd actually forgotten the difference (as laid down in GEDCOM) between Date Range and Date Period. In reality, there are a number of bits that are really missing from the GEDCOM date handling - like can I have "FROM ABOUT 1914", please FamilySearch?

As another aside, I notice GEDCOM 5.5.1 says

The preferred form of showing date imprecision, is to show, for example, MAY 1890 rather than ABT 12 MAY 1890. This is because limits have not been assigned to the precision of the prefixes such as ABT or EST.

While it's true to say that the precision of About and Estimated isn't established, the advice given isn't always useful - for instance ABT 1 MAY 1890 doesn't match MAY 1890 because MAY 1890 excludes the possibility of 30 APRIL 1890, which is indeed ABT 1 MAY 1890. Confused? You will be...

[tatewise]

Can't help with FROM ABOUT 1914
What about BET APR 1890 AND MAY 1890 as an alternative to ABT 1 MAY 1890?

[AdrianBruce]

... What about BET APR 1890 AND MAY 1890 as an alternative to ABT 1 MAY 1890?

Hmmm. I guess we're back to some sort of personal expectation around what ABT 1 MAY 1890 might actually mean, compared to what BET APR 1890 AND MAY 1890 means. (Leaving aside the question of whether the end-points are included in a Between And range...)