Looking for guidance/editing on building sentence templates to make the narrative reports more readable.
Here is my Census template: Census: <[Date:Plain]>,< [Place:Short:Plain]>< [PlaceDetails:]>, [person:HeShe] appered <as [Desc]> in the census.
Customize the sentence for every fact to preclude robotic repetition.
Or convert sentence templates to point form to make the narrative look more like a series of Individual Summaries without wasteful repetition of names, pronouns, verbs…
I use point form sentences. I very much prefer them to the normal way they are done. My templates do put a carriage return at the beginning of each template to make them start on a new line. For example, here is my Census template. I use the census note field rather than the description field because my census notes are more than one line long. The note prints automatically and there is no [Note] variable. I don’t use Place Details and you will need a [PlaceDetails] variable in the template if you use place details.
{cr} an invisible carriage return character goes here instead of the {cr} string
Census: <[Date:Plain]><,< [Place:Plain]>>.
A typical note for a head of household with a large family would look something like the following.
{cr} again an actual carriage return and not the string {cr}
Head of household. Dist. 9, Enumeration District 10, 14 Jun 1900.
page 129a, dwelling number 7, family number 7, enumerated by Calvin H. Scarbrough, owns farm, has mortgage.
Peters Alva E. 29 head male married 6 years, white, born Oct 1870, farmer, born in TN, father and mother born in TN
Sallie J. 29 wife female married 6 years, white, born Jun 1870, born in TN, father and mother born in TN, 2 children, 2 living
Earnest L. 5 son, male, single, white, born Feb 1895, born in TN, father and mother born in TN
Elsie C. 1 daughter, female, single, white, born Dec 1898, born in TN, father and mother born in TN
Hulda A. 54 mother female widowed white, born Dec 1845, born in TN, father and mother born in TN, 14 children, 6 living
John W. 23 brother male single white, born Mar 1877, born in TN, father and mother born in TN
Martha E. 12 sister female single white, born Jan 1888, born in TN, father and mother born in TN
Henry H. 10 brother male single white, born Mar 1890, born in TN, father and mother born in TN.
----- Alva was listed as the head of household, but his mother owned the farm. She purchased it in 1895 shortly after she was awarded a widow’s pension for the Civil War service of her husband John H. Peters. She and John never owned any land during John’s lifetime.
A typical note for someone other than the head of household in the same family would look something like the following.
{cr} again an actual carriage return and not the string {cr}
Household of her father Alva Edward (Alvy) Peters. Dist. 9, Enumeration District, 10, 14 Jun 1900.
Elsie C. 1 daughter, female, single, white, born Dec 1898, born in TN, father and mother born in TN.
1 Like
Thank you for those links, TomH
Wow that’s very interesting usage of the note field. So you basically add the information from the census about each person as it pertains to them. That will add a lot more to each person’s narrative report other than the BMD data. Thanks
You can see a full sample report at Sample RM Report The only thing different in this sample report and the way I do it now is that I no longer put a blank line between facts.
I really like your showing us examples. I am trying to set up a tag for examples, but I guess I need to ask for one to be put into use. Please, Rootsmagic, set up a tag for examples. Thanks much!
Well, my exact sentence templates for the Birth fact and for the Census fact are as follows. Remember that {cr} is really the carriage return character that you enter into RM with the Enter key on a PC and I assume with something similar on a Mac. Having entered such a carriage return into a sentence template, it will simply look like a blank line in the template. The Birth fact does not need the carriage return because it always will start on a new line, anyway. The Census fact will always have a note with most of the information, but RM doesn’t have a [Note] variable. It just includes all the notes by default unless you turn them off when you run a report. And I don’t use Place Details. So most of templates are actually very simple - much simpler than RM’s built-in templates.
[Person:Full].
<b>Birth: </b><[Date:Plain]><, [Place:Plain]>.
{cr}
<b>Census: </b><[Date:Plain]><,< [Place:Plain]>>.
1 Like
These look great, thanks. I do use some of your ideas and they look great. I just have to get use to setting up my facts and notes that way. Good job!
Jerry, I know from previous posts that you don’t use ‘Place details’ but I like to know and to document if a person was born at 12 Bluebell Lane or at London Maternity Hospital (for instance). Do you put this information in a Note? If you do how do you source this information ?
I do enter things like hospitals where people were born or died, churches where people were married, cemeteries where people were buried, and the like. In fact, I’m very insistent about including such information. It’s just that I enter such data as a part of the Place field rather than putting into the Place Details field. For my use of RM, putting such data into the Place Details runs too much of a risk of losing the data if I transfer the data out of RM and into some other software.
When Place Details were first introduced into RM, I eagerly embraced the feature and I spent hundreds of data entry hours changing my places to use Place Details. Several years later, I regretted my embrace of Place Details. But I was able to use an SQLite script to undo my use of Place Details rather than spending hundreds of entry hours. No data was lost when I embraced Place Details, and no data was lost when I rejected the use of Place Details. It’s just that the place where cemetery names and hospital names and church names was stored was changed.
For an example of data loss if you use Place Details, my experience is that Place Details don’t transfer from RM into FamilySearch. In fact, the place name standards in FamilySearch have historically not permitted things like cemetery names to be included in place names. But they seem to have changed the standard within the last year or two to support cemetery names. I don’t know if the same change supports things like hospital names and church names or not. I tried to find the announcement of the change just now. I was not able to find it, but I’m sure it’s there somewhere. In any case, even though FamilySearch now supports cemetery names, cemetery names will not transfer from RM to FamilySearch if they are stored in the Place Details field. They will transfer only if they are stored in the Place field.
It’s funny what it takes sometimes to notice something. When I put my sentence template for Birth right next to my sentence template for Census in my message above, it’s obvious that the Census template contains an unnecessary extra set of angle brackets around the [Place] variable. The extra set of angle brackets don’t hurt anything , but neither do they do anything nor are they necessary.
Not being a Family Search user this is not really of any import to me. I do however wonder why they would only allow cemetery names. Most of my burials are not in cemeteries anyway - they are in churchyards. I use the Place detail field for residence data, baptism data, marriage data as well as burial data. Seems a strange decision by FS
In the United States there is no real distinction between cemetery, graveyard and church yard outside of the fact that a cemetery doesn’t always have any affiliation to a church. Graveyards are burials in a churchyard, but they are still a cemetery, just a more specific form. We also seldom use the term churchyard when referring to a graveyard.
Here is an interesting bit on the history of the words. It was researched by Snopes in response to a certain meme that periodically makes the rounds. It is at What’s the Difference Between a Cemetery and a Graveyard? | Snopes.com
I can go with graveyard or churchyard for those attached to a church. In England we don’t usually refer to these as cemeteries. Cemeteries were introduced when the graveyards filled up in the cities in the 19th century and are mainly run by the town/city council. They are not aligned to a specific religion but may have areas that are specific as well as unconsecrated areas for those with no allegiance. In most villages people are still buried in graveyards if they are Anglican although it must be said that over 77% of people in the UK are now cremated, so my Place detail for most of my recently deceased people is a Crematorium with a Cremated fact.
And that is all well and good. The point is that a graveyard is a cemetery. So it is not incorrect to indicate your graveyard burials as cemeteries. How you choose to enter your details is up to you, but nitpicking graveyard/churchyard is rather pointless due to how the words have evolved into modern usage.
In the United States, cemeteries can be ran by city or county but they can just as often be ran by private for profit enterprises. There are even some ran and maintained by our federal government, most military in nature.
I have found that an increasing number of UK churches now have standard place names in FamilySearch, and for quite some time as I have added a Church or Cemetery to a place name, the suggested standard place name often has some variety of the extended name that I have entered.
I’m trying to parse out data from the [Desc] field that is comma delimited. For example: 45 Main Street, other info2, other info3. I want it to show in front of the [Place] field that contains town, county, state. The result to look like this: 45 Main Street, town, county, state Is there a way to do this?
Basically, no. You can’t parse the [Desc] field or any other field in the sentence template language. For a role variable that can represent multiple people such as [Groomsman] at a wedding, you can pick the first person or the fourth person or whatever. But that’s not the same thing at all as parsing a field by its commas or parsing a field in any other way.