Page 1 of 1

Data reference for witness

Posted: 03 Nov 2022 18:15
by ogulbran
Today I am using the expression {role=Rolename} in a sentence. The result lists the names of all witnesses that have the role Rolename. I would like to be able to use f.ex. a name part (given) or alternative name (name no 2) for these witnesses. Use of data reference would probably give me these opportunities? But what is the data reference syntax equal to {role=Rolename}?

Re: Data reference for witness

Posted: 03 Nov 2022 18:41
by tatewise
The way to discover such data references is to use a Data Reference Assistant and the easiest one to use is built into every Query Window on the Columns tab.
So run the standard Query > Facts and Events > All Facts and open the Columns tab.
In the box below the Fields pane, click the down arrow menu and chose Show Both in Box.
Now when you select any Fields the Data Reference will appear in the box below.

So click the [+] next to Witness> and then (Role) to reveal Data Reference %FACT._SHAR[1].ROLE%
That refers to the Role of the 1st Witness. If you have several Witnesses for the Fact that index [1] could be [2] or [3], etc.
So you have to test several such Data References to find the ones where Role = Rolename.

While there you can find the Data Reference for the Witness> Name :GIVEN which is %FACT._SHAR[1]>NAME[1]:GIVEN%
Where NAME index [1] refers to the Primary Name and NAME index [2] refers to the 1st Alternate Name.

So putting that together you need an expression involving the =TextIf(...) function such as
=TextIf( %FACT._SHAR[1].ROLE% = "Rolename", %FACT._SHAR[1]>NAME[1]:GIVEN%)
=TextIf( %FACT._SHAR[2].ROLE% = "Rolename", %FACT._SHAR[2]>NAME[1]:GIVEN%)
=TextIf( %FACT._SHAR[3].ROLE% = "Rolename", %FACT._SHAR[3]>NAME[1]:GIVEN%)

That must repeat for as many _SHAR[n] indexes as there may be Witnesses.

The 'gotcha' is that you probably need commas to separate each given name but those commas depend on which =TextIf(...) actually yields a given name, and so it gets more complex...

Re: Data reference for witness

Posted: 03 Nov 2022 21:11
by ogulbran
Thank you very much for your reply.

This illustrates that the {role=Rolename} is a very effective expression… I think it will be to complex (at least little practical) to achieve my goal of sentences (in several different facts) showing witnesses choosing one of the alternative names with a specific name type. My wish is to have a syntax like {role=Rolename.patronymic}, which would choose a name of type "patronymic" (own defined name type, preferably also so that it takes the primary name if no name of type "patronymic" exists). The background is that people in Norway usually were named by their patronymic plus their farm name (which could vary through their life). Probably I should in stead consider to have the patronymic only as the primary name, which then would automatically be used in f.ex. this witness listing. But that also has disadvantages.. May be some future release will have solutions that can help me?

Best regards,
Øivind

Re: Data reference for witness

Posted: 03 Nov 2022 21:46
by tatewise
What you are requesting is rather complex, so I doubt if any future feature will solve that problem.

Re: Data reference for witness

Posted: 03 Nov 2022 22:16
by AdrianBruce
tatewise wrote:
03 Nov 2022 18:41
...
In the box below the Fields pane, click the down arrow menu and chose Show Both in Box.
Now when you select any Fields the Data Reference will appear in the box below.
...
Thank you for that, Mike - I'd missed the Show Both option. If I was going to use the Query window, I'd have looked at putting the item into the right-hand side - but using Show Both is quicker - and the result can be selected and copied easily.

Re: Data reference for witness

Posted: 03 Nov 2022 22:19
by tatewise
Adrian, it also lets anyone use a standard Query where you cannot add the item to the righthand side!

Re: Data reference for witness

Posted: 03 Nov 2022 22:20
by AdrianBruce
tatewise wrote:
03 Nov 2022 22:19
Adrian, it also lets anyone use a standard Query where you cannot add the item to the righthand side!
True! ;)

Re: Data reference for witness

Posted: 04 Nov 2022 12:43
by davidf
ogulbran wrote:
03 Nov 2022 21:11
... a name of type "patronymic" (own defined name type, preferably also so that it takes the primary name if no name of type "patronymic" exists).
...
The background is that people in Norway usually were named by their patronymic plus their farm name (which could vary through their life). Probably I should in stead consider to have the patronymic only as the primary name, which then would automatically be used in f.ex. this witness listing. But that also has disadvantages.. May be some future release will have solutions that can help me?
Øivind,

I have been trying to get my mind around handling of name structures that do not follow the Anglo-Saxon GivenName(s)+Surname structure. You have highlighted another variation! This use of Name Type (which is FH7 only) I had not considered.

But see also in a previous thread:
https://www.fhug.org.uk/forum/posting.php?mode=quote&f=32&p=125710 wrote:In Norway it was not a requirement to have an inheritable surname until 1924, my rural family members born before that date were also on the patronymic naming standard as well. Many naming customs today include multiple surnames as well which may have non-surname parts between the surnames!
[This is a bit of a departure from "Data References for witness" - but is relevant if there is a way to handle names which brings the handling of your pattern of names back to within the intended handling (i.e. can we make the issue "go away"?). Multiple links are given so that further discussion can be added to those threads.]

The Knowledge Base article Names, Name Parts and Name Structures tried to consider patronymics and how FH can currently handle them (not particularly fluently). If your name format is consistently Given+Patronymic+Surname/FarmName you can use the :MIDDLE qualifier to extract the patronymic. However the emboldening in the previous sentence may not apply!

(The MIDDLE qualifier returns all except the 1st given name and /surname/ part from NAME so multiple given names would break the use of MIDDLE as a patronymic extractor)

The Forum Thread Surname prefix (SPFX) -- more generally, handling structured names attempted to get its mind around different name structures and I think we may have a proposed wish-list for Surname Prefixes in a later version. I am unclear what extra needs to be added to promote it to an actual Wish List Item.

I think we may need similar discussions around a potential wish list item for "comfortably" handling patronymics etc. for name entry and edit and for default "surnaming" of children. There seem to be a lot of variations; for instance:
  • Welsh which "can compound" - Llywelyn ap Gruffydd ap Morgan
  • Russian (=Slavic more generally?) Given + Patronymic + Surname, where the patronymic and surname are gendered - Pyotr Ilyich Tchaikovsky and his sister Aleksandra IIinichna Tchaikovskaya
  • Spanish (=Castilian?) Given + 1st part of father's surname "copulatively conjoined to" 1st part of mother's surname - Alejandro /Rodríguez de la Peña y de Y barra/
  • Scandinavian patterns etc.
Handling all variations is probably too complex and for the Anglo-centric may seem unnecessary. Trying to express ways in which these patterns could be easily and quickly handled by "native written" software might be helpful, because there may be comfortable "meet half-way" compromises that may be suitable for multi-cultural/multi-lingual software.

Re: Data reference for witness

Posted: 04 Nov 2022 16:02
by ogulbran
Thanks for your comments David.

The witness problem was in fact just one specific situation. As you are pointing out names are a more genereic challenge. I was trying to find a solution basesd on the possibilities in FH - and when I was aware of the name type property I wanted to test out if that could help me.

I was a TMG user earlier. The solution in that product was as I see it quit good. For every fact you could choose which name variant you wanted to connect it to. This name variant would then be used in the narratives. If no name variant was chosen the primary name would be used. That solved "all" my name problems…

Another approach could be to have dates steering the use of names. If name variants had start dates this could be incorporated in the sentence construction.

None of these points are really focusing the name structures that you are discussing, which also are very relevant. This is more possible solutions for names varying over time.

I was not aware of the "middle" qualifier. I will check out if that can help me some way. A challenge can be that not every person has a patronymic (and then no name will be returned if I understand right) - and many people do have two given names plus patronymic plus farm name. A suggestion for development could be to establish a qualifier "surname1", defined as the first of surnames. That would assume that patronymics was in the surname field (which I do not do today, because how I want the searching for surnames to work…). Such a definition would return the patronymic if a person has one - and the surname for other persons (which is wished functionality).

Best regards,
Øivind

Re: Data reference for witness

Posted: 04 Nov 2022 17:48
by davidf
ogulbran wrote:
04 Nov 2022 16:02
I was a TMG user earlier. The solution in that product was as I see it quit good. For every fact you could choose which name variant you wanted to connect it to. This name variant would then be used in the narratives. If no name variant was chosen the primary name would be used. That solved "all" my name problems…

Another approach could be to have dates steering the use of names. If name variants had start dates this could be incorporated in the sentence construction.
I have started a new thread for further discussion of Name Variants - Names and Name Changes over time (21126). Currently, it sits in General Usage - the mods may decide that it is a nascent wish list request and may move it.

Re: Data reference for witness

Posted: 04 Nov 2022 18:57
by davidf
ogulbran wrote:
04 Nov 2022 16:02
A challenge can be that not every person has a patronymic (and then no name will be returned if I understand right) - and many people do have two given names plus patronymic plus farm name. A suggestion for development could be to establish a qualifier "surname1", defined as the first of surnames. That would assume that patronymics was in the surname field (which I do not do today, because how I want the searching for surnames to work…). Such a definition would return the patronymic if a person has one - and the surname for other persons (which is wished functionality).
I have started a new thread for considering Patronymics: Patronymics (& Matronymics/metronymics)