Re: Additional info on shared people

Mike Tate

As a human, I understand the concept you are trying to achieve, but that has to be translated into a Sentence Template expression that FH understands.


The place, date, address, and note references that you mention all operate in the context of just the Principal fact.


To identify the Fact Witness person with more than Name and Record Id needs some other data to be extracted from that person’s record.


Where would the Place of Boston exist in the Joshua record?

Likewise, where would it exist in the other Joshua record?

Place details only appear in Facts.

So which Fact with an appropriate Place can you ensure exists in each Fact Witness person’s record.


Anyway, I think any such technique is doomed to failure as explained below.


Looking back at your original posting you refer to:

2 _SHAR @I2@
3 ROLE father
3 _SENT {individual} was father of {principal} < in the [date:YEAR] census>

That Sentence appears in father’s Narrative Report amongst all his other facts, so you know who the father is without needing extra identification in that Sentence.

What you might need is extra identification of the Principal where {principal} only provides the Name.


It is the Principal fact Sentence Template that needs the extra identity of Witnesses and the expressions that matter are the ones you posted later:

<<br>   heirone: {role(single)=heirone}><<br>   heirones: {role(plural)=heirone}>

The angle bracket conditional structure <<br>   heirone: {role(single)=heirone}> is only allowed one variable item in curly brackets which must be the {role…} item.

So any data reference to any other additional item such as {%CUR~WITN.NOTE2%} will not work because two variables items are not allowed.

Sometimes it is possible to replace an angle bracket conditional structure with the {=CombineText(…)} function but in this case the crucial {role…} item is not supported inside such functions.


If differentiating one Joshua Smith from another with more than just Record Id is important in the above contexts then it is probably important in other contexts.

So the only general solution I can offer is to add that differentiation to the Name field of each Joshua Smith.


Name: Joshua /Smith/ from Boston

Name: Joshua /Smith/ from Chicago

Name: Joshua /Smith/ Junior

Name: Joshua /Smith/ Senior from Detroit


In reports and diagrams where you don’t want that suffix after the surname, then it should be possible to use one or other of the NAME qualifiers to exclude it.


Join { to automatically receive all group messages.