Sequence of Roles appearing in a sentence

I am not sure why, but using the Role in a sentence does not seem to ‘order’ or ‘sequence’ multiple people for the role. It seems completely random, which in turn looks a bit wonky on reports.

For example, in the sentence template below, I added the roles of Daughter and Son. In the place where this event happens. There are multiple of each in each event.

<Living in the home with them were:<
Daughter(s): [Daughter]><
Son(s): [Son]>

So, in event 1, they may appear as:

Living in the home with them were:
Daughter(s): Mary Contrary, Jenny Contrary, Sue Contrary
Son(s): John Contrary, Randy Contrary, Tom Contrary

Then, in the very next event 2 using the same sentence template, they might appear as:

Living in the home with them were:
Daughter(s): Jenny Contrary, Mary Contrary, Sue Contrary
Son(s): Tom Contrary, Randy Contrary, John Contrary

They are not organized alphabetically, chronologically, or in the order in which I shared them to the fact. Is there any way to control a consistent sequence with which they appear?

I am not sure if they should appear in alphabetical order,

Does this need to be a feature-request or is this an issue requiring a support ticket to fix?

1 Like

@tstrickland Would you please post the whole fact sentence you have for the principal and then say the one you have for Daughters ( as sons should be the same) as what you have posted here
<Living in the home with them were:<
shouldn’t work and I’ve never been able to get a fact like this to work

I don’t have the sentence that the OP is using, but I think I can describe the concept.

There are two sentences involved - a sentence for the fact and a sentence for the role, and it’s a two way street. The fact sentence can contain the names of the people with the roles, and the role sentence can contain the name of the person with the fact.

I’ll give a different example than the one from the OP. Suppose you wanted to list the name of the midwife (if known) on a person’s Birth fact. You would share the Birth fact with the person who was the midwife using role of Midwife. The sentence for the Birth fact might be something like the following (and I’m making no effort to get every detail of the sentence just right - it’s just an example of the concept).

[Person] was born [Date][Place].<The midwife was [Midwife].>

Now suppose there were two midwives and you shared this birth fact with both of them. In that case, the single [Midwife] variable would expand to both of them. But if you were expecting that ever to happen, then you would need to put some effort into making the sentence smarter to include plural switches so that it could automatically say “The midwife was …” or “The midwives were …”.

As to the thrust of this question, my experience is that when there are multiple people with the same role, they are listed in reports in the order in which the were shared. That’s where it gets tricky.

You can share people one at a time for a fact, in which case you get to choose the order. You can choose the same people for the same role for different facts and the order can be different if you did the sharing in a different order for the other facts. If you get the order wrong, there is no way to fix it except to delete the shares and to put them back in, this time in the correct order.

You can share people all at the same time for a fact, in which case you do not get to choose the order. In this case, the order is based on the RIN numbers of the people being given the roles. For that reason, I never share people with the same role all at the same time. For whatever reason, I care mightily about the order. So I do the sharing one person at a time, even though it’s more work to do it that way.

I actually make very little use of shared facts. I generally speaking prefer separate unshared facts for each person. My chief exception is that I have a Parents fact which is shared with each of the person’s parents. To make my reports consistent, I always share with the father first and the mother second. I use the same role of [Parent_of_Child] for each parent. I could have made separate roles for [Father] and [Mother], but I prefer the sentence structure when both parents are in the same sentence with the same role.

Back on the concept that there are two sentences involved. I have a very simple use case. But I can imagine use cases where a fact is shared and the people with the role show up in the fact sentence and there is no role sentence. And vice versa, I can imagine use cases where a fact is shared and the people with the role do not show up in the fact sentence but where there is a role sentence. It’s a very flexible tool, and sometimes you need to be flexible and creative in the way you use it.

But just to repeat my experience, the order in which multiple people with the same role are listed in reports as based on the order in which I did the shares. I can even see using SQlite that the order shows up implicitly in RM’s WitnessTable where the witnesses for each event are stored. Multiple people with the same role for the same fact are stored in WitnessTable in the order in which I did the shares.

For whatever it’s worth, but my fact sentence for the my Parents fact is extremely simple.

Parents:< [Parent_of_Child].>

However, the role sentence is a little more complicated.

Birth of Child: <[Date:plain]><, [Person:Full]><, [Place:Plain]><, age of <%ThisPerson%father|mother>: [ThisPerson:age:plain]>.

It’s hard to tell on this forum, but both sentences start with a carriage return (Enter key on a Windows machine) to cause the fact to start on a new line. The … tags cause the name of the fact or role to print in bold.

The role sentence has the really nice effect of creating a “Birth of Child:” item in each person’s timeline, along with items such as Birth, Marriage, Death, and Burial. It’s a very nice effect in narrative reports that I print out for family reunions. You can see the same information as an option in the Edit Person screen, but seeing it on the Edit Person screen does not get it into narrative reports in the person’s timeline.

Finally, as to your question as to why the order might be different for two different facts in your use case: I believe my description of how it works is correct. So my guess is that you might have done the shares one at a time for one of the facts and all at the same time for another of the facts. For example if there were three sons, you might have shared two of the sons at the same time and the other son separately on one fact and then have shared all three sons at the same time on the other fact. It’s certainly possible that my understanding of the ordering may be incomplete, but I have never seen an exception to the ordering rules I have described. After doing the sharing, it can be almost impossible to remember the exact order you used for the sharing.

Here is what I have on the Principal role:

[couple] had a home< [PlaceDetails]>< [Date]>< [Place:Abbrev]>.
<i><Living with them were:</i><
<b>Daughter(s):</b>  [Daughter]><
<b>Son(s):</b>  [Son]><
<b>Husband's father:</b>   [HFather]><
<b>Husband's mother:</b>   [HMother]><
<b>Husband's sister(s):</b>  [HSister]><
<b>Husband's brother(s):</b>  [HBrother]><
<b>Wife's father:</b>   [WFather]><
<b>Wife's mother:</b>   [WMother]><
<b>Wife's sister(s):</b>  [WSister]><
<b>Wife's brother(s):</b>  [WBrother]><
<b>Niece(s):</b>  [Niece]><
<b>Nephew(s):</b>  [Nephew]><
<b>Boarder(s):</b>  [Boarder]>
>

The result looks like:

Joseph Smith and Lottie Mae Jones had a home at 414 South Collington Avenue on 27 April 1910 in Baltimore, Maryland.
Living with them were:
Daughter(s): Alice May Smith, Edna Marie Smith, Hilda Smith, and Lottie Mae Smith
Son(s): Joseph Smith Jr

It took a lot of experimenting for me to figure out, with the help of kevync1985, exactly how to get the proper line breaks.

For the person which has the role of Son, for instance, I have a different sentence in use for them.

[ThisPerson] was [ThisPerson:Age] when living in the home 
of his parents< [Date]>< [PlaceDetails]>< [Place:Abbrev]>.

Which, on that Son’s edit page only, results in:

Joseph Smith Jr was at the age of 5 when living in the home of his parents on 27 April 1910 at 414 South Collington Avenue in Baltimore, Maryland

Nancy, I use a simpler sentence structure, that incorporates all the people in the household for the head of household sentence -

[Person:Cycle:Casual], [Person:Age], was enumerated as the head of household in the< [Date:Year]> Census< [PlaceDetails]>< [Place:Short]>. [OtherPersons:First], [OtherPersons:Age] <#OtherPersons #was|were> also living in the home.

The sentence reads " James, at the age of 35, was enumerated as the head of household in the 1871 Census at Maryhill in Glasgow, Scotland. Elizabeth, Thomas, James, John and Elizabeth, were also living in the home.

Note: [OtherPersons] gives a list of people who share the fact but not the role name which could provide relationship context. And as noted in another thread. The ages of the “others” does not work. (on a side note, the order the names appear is not by RIN, but in the order they were shared.)

The sentence I use on a “sharee” is structured:

[ThisPerson:Cycle:Casual] was enumerated as< [ThisPerson:Role], [ThisPerson:Age],> in the household of< [Person]> in the< [Date:Year]> Census< [PlaceDetails]>< [Place:Short]>.

Reading - Elizabeth was enumerated as spouse, at the age of 35, in the household of James Watt in the 1871 Census at Maryhill in Glasgow, Scotland.

2 Likes

My experience is slightly different than that. If I share the names one at a time, they are listed in the order I share them. But the sharing dialog also supports selecting several different names at the same time. If I do it that way, then the names are listed in RIN order. And even in that case, the names are not truly “listed in RIN order”. Rather, it’s that the dialog of selecting several different different names at the same time has the effect of selecting them in RIN order. So either way, they are listed in “the order I select them”. It’s just that “the order I select them” has a different meaning when I select more than one at the same time.

1 Like

hmm - have to look at that a little closer.
I thought might it have to do with order of creation – but event #1 & #2 suggest that might not the case – check the order they appear in shared lists for both?
are they they same order and / or do they match events #1 & #2?

I suspect we need a sort order enhancement

I don’t use the group add when sharing so I can’t speak to how that operates. In terms of this shared list, it appears as I entered based on order in the census, which in this case is by relationship (spouse then children) and age with children listed in age order.

Elizabeth (spouse) - RIN 388
Thomas (son b. 1857) - RIN 389
James (son b. 1861) - RIN 533 - my direct ancestor
John (son b. 1868) -RIN 390
Elizabeth (daughter b. 1871) RIN 391

That reminded me that I had written a script to sort the ‘witness’ order for RM7 in a particular way. It’s an example of how such an enhancement could operate on the current data structure. It still works on RM12 databases.

While it illustrates an exploit of the current structure, the bigger development effort would be on the user interface to provide choice of sorting criteria, selection of fact types, Principals, roles to which it should be applied…

And then there’s the matter of how captive this effort may be. Is it trapped in one database file? Would any of the very few apps that can import RM’s shared events respect a custom sort order?

Yes, that’s precisely how it works for me when I share one person at a time. The RIN order only seems to come into play when there is a group add.

Yes - Used an adapted version of it before.

The ask is rather simple – they simply need to store the variables / criteria. Have a “view” the can execute that view when needed. One could choice diff combinations, by role name (alphabnetical), RoleID. otherfield or even by Consang distance as in set relationships etc.

Good question – one example comes to mind is GEDSITE - but it mind depend on GEDCOM (in part anyways). Not sure if GED7 has a noticeable advanage for sorting purposes.

In GEDCOM architecture, shared facts and fact sorting involve distinct specifications and program-level implementations.

1. GEDCOM & Shared Facts

Traditional GEDCOM (5.5 / 5.5.1) vs. Modern Specifications

  • Standard GEDCOM 5.5.1 does not natively support sharing individual facts (such as a single Census or Residence event) across multiple INDI records using roles (e.g., Household Head, Witness, Neighbor).

  • In standard 5.5.1, shared events only occur natively at the Family (FAM) record level for couple-centric events (e.g., MARR for Marriage, DIV for Divorce, or family CENS / RESI).

  • Extension/Vendor Implementation (RootsMagic, Family Historian, Legacy, etc.): To allow multiple individuals to share a single event, desktop software typically utilizes non-standard custom tags (such as _SHARED, _ASSCL, or custom ASSO / ROLE structures).

  • GEDCOM 7.0: Introduced formal ASSO (Association) structures with predefined and custom ROLE tags subordinate to event structures, standardizing shared event links and witness capabilities.

Database vs. Export Behavior

When exporting shared facts to a standard GEDCOM 5.5.1 file:

  • Primary Owner: The main individual record retains the core event (1 EVEN, 1 CENS, etc.) along with date, place, source citations, and notes.

  • Witnesses/Shared Participants: Depending on export settings, software will either:

    1. Export custom vendor extension tags (e.g., 1 _SHARED or 2 _STAT) readable primarily by identical or compatible software.

    2. Duplicate the fact structure as a separate individual event under each shared participant’s INDI record to preserve visibility across generic GEDCOM importers.

2. Event & Fact Sorting Rules

Standard GEDCOM Sequential Rules

GEDCOM structure rules dictate that all Level 1 attributes and events (1 BIRT, 1 OCCU, 1 DEAT, 1 BURI, etc.) appear under the main record (0 @I1@ INDI).

  • The standard specification does not require exporting programs to write Level 1 facts in strict chronological order, though most modern genealogy software sorts them chronologically by default upon file generation.

  • Tag Priority vs. Chronological Placement: In standard GEDCOM, primary vital events (like BIRT) often appear near the top of the record structure, followed by non-vital life facts (RESI, OCCU, CENS), and ending with post-death events (DEAT, BURI, PROB).

Program-Specific “Sort Dates” vs. GEDCOM Dates

  • DATE Tag (2 DATE ...): The human-readable or standard genealogical date string exported to the file (e.g., 2 DATE ABT 1885 or 2 DATE BET 1900 AND 1910).

  • Sort Dates (Internal Database Field): Software such as RootsMagic uses an internal SortDate field (often stored as an integer/YYYYMMDD key) to control display sequence on-screen.

  • GEDCOM Export Behavior: Sort dates are not part of the core GEDCOM 5.5.1 specification.

    • If a fact has no official DATE line, desktop software uses internal sort ordering to display it in sequence.

    • When exporting to GEDCOM, if no DATE tag exists, importing programs may place undated facts either at the top of the timeline, bottom of the timeline, or group them under generic “Attributes” depending on the importing algorithm.

    • Some systems export custom tags like 2 _SORTDATE or 2 _DATE to preserve non-standard sort keys across systems.

      Key Recommendations for GEDCOM Interoperability

      1. Handling Shared Facts Across Software: If transferability between different programs is critical, evaluate whether to export shared facts as duplicated individual facts rather than relying solely on custom software tags (e.g., _SHARED or _ROLE).

      2. Preserving Timeline Order: Ensure facts have a valid GEDCOM-compliant DATE string. Relying solely on software-specific sort dates without a populated DATE tag will cause importing applications to fallback to arbitrary sorting (e.g., sorting undated facts to the top/bottom or by record creation order).

Thanks Jerry BUT wanted to ask you why this sentence above works as written..

I was always told you had to have the chevrons

[Person] was born <[Date]><[Place].> <The midwife was [Midwife].>

Thanks for posting the sentence-- took me a while to figure out that I needed to take one chevron out so that it printed as you said instead of like this

it is now like this

and that is how it is going to print in Reports Daughters(s) Son(s)

Think I need a switch BUT NOT sure how

edit – Tim on your individual sentences for dau, son etc, you could add the relationship if you want

[ThisPerson], their daughter age [ThisPerson:Age:Plain], lived in the home of [Couple]< [PlaceDetails:Abbrev]>< [Place]>< [date]>.

2 Likes

complex sentence can power by brutal at times and even AI gets tripped. I need to practice more myself

You do when controlling spacing and punctuation that is dependent on there being a value for the variable. Compare the first sentence of those two examples to the default sentence template (first one) for Birth.

1. [person] was born< [Date]>< [PlaceDetails]>< [Place]>.
2. [Person] was born [Date][Place].
3. [Person] was born <[Date]><[Place].>
  1. has proper spacing and ending period no matter which variables have values.
  2. has a space between “born” and the period if Date and Place are empty. If Date and Place both have values, there’s no space character between them.
  3. has no ending period if Place is empty and no space character between Date and Place if both have values.

The second sentence in your template probably should have a space character before “The” and be tight against the preceding sentence so that it receives no trailing space character when Midwife is empty. That is:

[person] was born< [Date]>< [PlaceDetails]>< [Place]>.< The midwife was [Midwife].>
1 Like

@tstrickland, I think from experimenting a bit this evening:

  1. Shared one at a time, listed in the order shared
  2. Shared several at a time (cluster), listed alphabetically by name
  3. A mix of the two will be in order shared with each cluster sorted by name
  4. On top of this is that the Role is the top level sort in order created, not alphabetical

I examined the WitnessTable directly in addition to inspecting the fact sentences after sharing in these different ways. I did non-alphabetical order of adding children so the RINs are not sequential by name. Likewise, I did non-alphabetical assignment of roles in sharing the Residence (family) event with them. At no point did the WitnessOrder value for each share become non-zero.

The script I referenced earlier assigned values from -1 to 4 identically to each of the 6 repeat ‘witnesses’ to each target event, regardless of role, RIN, cluster and order shared, resulting in the {Son], [Daughter] and [OtherPerson] variables outputting them alphabetically.

2 Likes

This is a puzzle. When I look at me messages on my screen, it appears that all required angle brackets are there. This forum is obviously a Web site and HTML typically treats angle brackets as special characters rather than as literal text data. So pasting text with angle brackets onto a forum such as this can sometimes cause problems and the angle brackets sometimes need to be escaped in order to appear on the screen correctly. But this forum seems to have very robust support for the ability to paste text with special characters without needing to do any special escaping.

So in answer to your question: yes, angle brackets are frequently needed in RM’s sentence templates and source templates. I try always to include them when I paste, and I apologize if one was missed somehow or other.

2 Likes

@thejerrybryan and @nkess, the angle brackets are only needed if the data you intend in that part of the sentence appears optionally in your data. For instance, [Date] is not required in almost every Fact Type, although almost everyone puts in a year or something. So, if you do not provide brackets to the sentence template, you might (probably will) see strange amounts of white space mid-sentence in a report. Using < [Date]> prevents that.

This is actually the logic on why you don’t need the brackets for some parts, like [Person], as that will always be present.

Using the brackets also allows you to add punctuation, like a comma, if you are wishing to enforce certain grammatical norms. Some people might want a comma, for instance, if a date part of the sentence appears at the end and doesn’t use the “on” part, e.g. <, [Date:Plain]>.

2 Likes