Narrative sentences for shared facts not picking up field data

I am not getting RootsMagic to use the field data in shared facts. I have reset the sentences to default (even though I never changed them), but that did not solve the issue. Here are the examples from shared residence facts:

For main person, the sentence reads: He and his family lived as renters at 3211 South Fox Street (now Throop Street) in Chicago, Cook, Illinois, United States on 15 Apr 1910.

For the family members who share this fact (wife, daughter, son), the sentence reads: [HeSheFirst] was [a] [-EventRole] who resided in the of [MainPerson] on 15 Apr 1910 in Chicago, Cook, Illinois, United States: as renters.

Any insights as to what is happening would be appreciated.

I would like to be able to play with in on my own system to be sure, but I think the following are problems.

  • [HeSheFirst] needs to be [ThisPerson:HeShe:First]
  • [-EventRole] won’t work because shared facts don’t work that way. The role names only work in the sentence for sentence main person. It’s like if there was a Marriage fact that was something like [Couple] was married [Place][Date]. <The best man was [BestMan].> But the [BestMan} variable and and the best man role name are not available for the BestMan role sentence. Instead, the sentence needs to be something like [ThisPerson] served as the best man at the wedding of [Couple]. In other words, the name of the role has to be hardwired into the sentence. Because of that, you will need separate roles and separate role sentences for wife, daughter, son and the like.
  • [MainPerson] won’t work. It needs to be [Person] instead.

This is a pretty quick and dirty answer and I haven’t fully tested all the possibilities. But this still is the correct idea for how shared facts work. The way I think of it, there really aren’t any shared facts. Instead, facts can have roles and it is the roles that are shared. The key variables in the role sentences are [ThisPerson] for the name of the person sharing the role, and either [Person] or [Couple] for the name of the main person or main couple. Variables such as [Date] and [Place] work the same in the role sentences and in the main sentence. It’s only in the main sentence where the role names come into play, such as my wedding example where in addition to [BestMan] you could have [BridesMaid] or [FlowerGirl] or [Officiant] or the like. But those variables are supported only in the main sentence. In the role sentences, it’s [ThisPerson] for the role person and [Person] for the main person.

I believe something along the lines of [ThisPerson] was [ThisPerson:Role] works.

I would be pleased to be proven wrong, but I don’t think the ability to pick up the role name in the role sentence is supported. I was hoping your example might work, but I tried [ThisPerson:Role] role just now, and it didn’t work for me.

A simple sentence but it works for me.

Ok, so it seems the default sentences in RootsMagic (they are not sentences I created) don’t work. I am going to put this in as a ticket to RootsMagic Support. Maybe they can fix it ;P. In the meantime, I’ll try the suggestions here and see if I can make them work for me. Thanks to all for the possible fixes.

The “default” sentence template is whatever someone has set it as in the Edit Role Type dialog. It is not some built-in hard-coded template. Create a new RootsMagic file and get into the Fact Types dialog to see what RM originates. Compare that to what you have in your working database and you will see the differences. I think the only time you see the “Reset to default” is in the “Customize sentence” dialog for a given fact which allows you to override the fact type default with one just for that instance of a fact. The reset deletes that particular override and returns the sentence to the Fact Type default, whether the default itself is original or customized.

Much thanks. I have now gotten it to work, and I am pleased to have been corrected. My previous attempt to make it work had a typo that was hard to see and that was preventing it from working.

1 Like

As a side note, I would like to make a comment on your Screen dump. I see there that the Use description field is not checked.

I have seen that on new installations of RM9, 9,1.3.0 this checkmark is missing on many Facts.

I have created a ticket here and Development has been notified.

I don’t know that this is an error; it may reflect a GEDCOM spec (or common practice or the conventional use in the early 2000’s) for that fact type.

I basically did a quick check on RM 7 and RM 8 for the Christening fact and desc was NOT used there either-- also ran thru all 3 databases and basically only certain ones use the description field–hard for me to tell how many as I have added the description field to some that didn’t have it…

Yes, there has been no change in the Fact Type default settings since RM4 in 2009 and probably not since RM3 and maybe even Family Origins because the GEDCOM 5.5 standard was set in the mid-90’s. Even this partial example for an individual from the standard does not use an Event_Descriptor for the bolded facts.

0 @1@ INDI
1 NAME Robert Eugene/Williams/
1 SEX M
1 BIRT
2 DATE 02 OCT 1822
2 PLAC Weston, Madison, Connecticut
2 SOUR @6@
3 PAGE Sec. 2, p. 45
3 EVEN BIRT
4 ROLE CHIL
1 DEAT
2 DATE 14 APR 1905
2 PLAC Stamford, Fairfield, CT
1 BURI
2 PLAC Spring Hill Cem., Stamford,

RM places the value from the fact’s Description field as an appendage to the tag, in the same position as if it was for the EVEN tag, as in this quote from the spec:
EVENT_DESCRIPTOR:= {Size=1:90}
Text describing a particular event pertaining to the individual or family. This event value is usually
assigned to the EVEN tag (emphasis added). The classification as to the difference between this specific event and other
occurrences of the EVENt tag is indicated by the use of a subordinate TYPE tag selected from the
EVENT_DETAIL structure. For example;
1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointments
2 DATE FROM JAN 1952 TO JAN 1956

While RM does not preclude the use of the Description field for such fact types, not all other software back then imported it and maybe some still do not. I think that’s why it was not enabled for many fact types but the user is allowed to make their own choice.

Also, there has been recurring discussion about enhancing the Description field data entry/edit by applying the Note Editor to it and about truncations. That, too goes back to the GEDCOM 5.5 standard which RM does not fully respect. This old page looked into the issues during RM6:
https://sqlitetoolsforrootsmagic.com/gedcom-dnd-event-description-length-anomalies-bugs/

2 Likes

Thank you, Tom! It seems that I must have made (or more likely copied from another user) those sentences ages ago, as a new RM9 file does not have any sentences for these shared roles. And they migrated over from RM7 and RM8. I am working on editing those sentences and am seeing success!

Yay! Success. This sentence structure – [ThisPerson], [ThisPerson:Role] of [Person], lived with [Person:HimHer:First] < [PlaceDetails]>< [Place]>< [Date]> – yielded this narrative – Anna, wife of Pafnucy “Paweł” LATKO, lived with him at 3211 South Fox Street (now Throop Street) in Chicago, Cook, Illinois, United States on 15 Apr 1910. I did need to change the role from “Wife” to “wife”.

Again, thank you!

2 Likes

I’m an experienced RM user who after many years learned just today that [ThisPerson:Role] actually does work to include the role name in the sentence. Previously, I didn’t think there was any way to get the role name into the sentence. Getting the role name into the sentence in turn requires the role name in the Fact Type list to match exactly with the way you wish the role to appear in the sentence.

But you still really need separate roles such as wife, son, daughter anyway when you are sharing a census fact with other family members. Under those circumstances, there is no loss of generality in simply hard coding the role name in the sentence instead of using [ThisPerson:Role]. And when you hard code the role name in the sentence, the exact appearance of the role name no longer really matters as in your wife vs. Wife dichotomy.

Using the [ThisPerson:Role] construct instead of the literal words in the templates does permit the identical sentence template for those roles but that is only a one-time, trivial advantage.