* TNG and FH event witnesses standoff

[koalastamps]

Helen, thanks for weighing in.

I have provided the information here exactly as it was provided to me from TNG.

But it's problematic. Mike isn't updating his plugin anyway.

[ColeValleyGirl]

Using the TNG demo, it appears that TNG only supports adding an association between two people (not between a person and an event); there is also the option to create the reverse association so that the relationship is symmetric. So, it has a completely Gedcom-compliant data structure at the expense of the flexibility that the FH _SHAR tag allows.

Massaging the _SHAR data in FH prior to import into TNG using only custom tags can only achieve limited results.

Option 1:

Moving the detail of the event 'witness' into an ASSO association between the event 'owner' and the event 'witness' with a RELA field describing the nature of the relationship for the witness (Possibly "<Role> at <Event>") possibly with a reverse association with a relationship for the owner (Possibly "<Witness> was <Role> at <Event>").

Option 2:

Moving the _SHAR data into a note associated with the event.

If you want to adopt Option 1, your solution could either be a one-off plugin to migrate your existing data within FH and then using the Association feature as previously described or (if you really want to retain the Witness functionality within FH) a step in the export plug-in to create the ASSO tags that TNG will understand.

If you want to adopt Option 2, the solution could either be a one-off plug-in to migrate your witness data into Note(s), and then create the Notes that record future 'witnesses' manually, or a step in the export plug-in to do the same (I *think* Mike's plug-in can do this already?) .

FWIW I use neither the ASSO or _SHAR functionality (your problems illustrate the reason why); I create notes linked to the events that document the 'associations'.

[koalastamps]

Thanks Helen, I've just been experimenting with an ASSO import into TNG also. I knew nothing about this tag previously until being straightened out about it here.

Everything you say is correct. I ended up with an association on my mother's record like this:

Association: Rodney Allan Tilyard (Relationship: witness at her death)

and I had to provide the text 'witness at her death' on the RELA tag (as you pointed out, there is no tie to an event with the ASSO tag).

Nothing like what I was expecting (ignorance is bliss).

So I've messaged Darrin asking if he could consider supporting facts with witnesses with a future release.

In the meantime, I'll remove _SHAR tags from my gedcom import to TNG to avoid unexpected results, like my untimely demise.

[tatewise]

Rod, in the Export Gedcom File Plugin on the Extra Options tab there are Witness Role 2 _SHA%u: options.
So having selected the Basic Options for TNG try those Witness Role options.
The default for TNG is to Keep Custom Tags, but you could try Move to Fact Note or Remove entirely.
(Do not be fooled into using Change to 2 ASSO that is a special for Heredis and nothing to do with 1 ASSO.)

I have never said I would not update my Plugin, but just that the mapping from 2 _SHAR to 1 ASSO is complex, and I think you are starting to realise why. I was not going to waste my time trying to code that mapping until the objectives were very clear. Unfortunately, when it comes down these product migration issues the users have to get their hands dirty with the technical details. Thankfully GEDCOM exists, as without it we would all be completely at sea, but it is the non-standard GEDCOM extensions like _SHAR that cause many (but not all) of the the issues.

[AdrianBruce]

... This is what TNG expects:

Code: Select all

1 DEAT
2 DATE 23 JAN 2000
2 PLAC Brisbane, Queensland, Australia
2 AGE 70y
2 CAUS heat stroke
1 ASSO @I496
2 TYPE INDI
2 RELA Witness (or something else to describe the nature of the association)

...

You may have already twigged this but it seems to me that the only explanation for all this is that TNG is using the position of the ASSO tag to associate it with the DEAT event immediately preceding. Now that is definitely non-standard GEDCOM practice because, unless I'm mistaken, the order of tags of the same level is not supposed to be meaningful, other than the simplistic "list in this order please". Quite apart from anything, it is surely at risk of re-ordering at any time????

The standard meaning of a GEDCOM ASSO tag is that the 2 individuals are associated. Nothing about association via an event. If there were, there would / should be dates, etc, subordinate to the ASSO. There aren't. So the only way that TNG can bring an event into play is via physically expecting one after the other. Or at least, that's my belief, and which conclusion you may have already come to yourself!

[tatewise]

You are absolutely correct Adrian, and just two messages ago Rod has experimented and found the same.
As we have said several times, ASSO only links Individuals, and has no links to Facts.
So we are bemused that Darrin of TNG is suggesting it is the solution Rod was looking for.

[koalastamps]

"So we are bemused that Darrin of TNG is suggesting it is the solution Rod was looking for."
And that's being polite.

Thank goodness for your plugin Mike, I'm able to effortlessly remove _SHAR from my gedcom using it.

[tatewise]

Usually Darrin is very competent and helpful, so I can only assume that somehow Darrin & Rod got their wires crossed.

[koalastamps]

From me to Darrin:

... I thought I read that TNG now supported shared events and I took that to mean witnesses to events. Anyway, on Family Historian I have quite a few of these. For example, My brother and I were witnesses at our mother's death and I have the appropriate witnessed events set up there.

After the FH import, both my brother and I showed as dead, with our mother's death date, along with her cause of death (heat stroke).

Darrin's response:

Hi Rod,

Here's what I see:

1 DEAT
2 DATE 23 JAN 2000
2 PLAC Brisbane, Queensland, Australia
2 _SHAR @I497@
3 ROLE PRESENT
2 _SHAR @I496@
3 ROLE PRESENT
2 AGE 70y
2 CAUS heat stroke

That tells me that you've shared your mother's death event with you and your brother, which is why you're all deceased. I can't see anything that would indicate you were intending to export an association.

Darrin

and then:

When TNG sees _SHAR, it thinks you want to duplicate that event for the people mentioned. If you don't want to do that, then you shouldn't use the _SHAR tag at all. TNG does associations (what most people use for witnesses) with the 1 ASSO tag, as per the GEDCOM standard.

[tatewise]

It seems that the TNG implementation is taking _SHAR as literally meaning a SHARed fact without considering the meaning and purpose of the subsidiary ROLE, which conditions the sharing relationship.
i.e. Death ~ Witness, or Marriage ~ Bridesmaid, or Will ~ Beneficiary.

If there was no ROLE defined, then a simple SHARed fact is the only interpretation.
But the ROLE defines the sharing relationship, and I am surprised Darrin/TNG disregards that relationship.
Especially since the semantic model exists in The Master Genealogist, Legacy, RootsMagic and FH.

Darrin also talks about "intending to export an association" so presumably there was some earlier dialogue that discussed 'associations' and the ASSO tag, which perhaps fuelled some misunderstanding?

[koalastamps]

"... I am surprised Darrin/TNG disregards that relationship."

You tell me, this is the code:-

case "_SHAR":
$share = new stdClass();
if(preg_match( "/^@(\S+)@/", $lineinfo['rest'], $matches )) {
$share->id = $matches[1];
$lineinfo = getLine();
while( $lineinfo['level'] >= $prevlevel + 1 ) {
$note = array();
switch($lineinfo['tag']) {
case "ROLE":
$note['NOTE'] = $admtext['role'] . ": " . addslashes($lineinfo['rest']);
$share->notes[] = $note;
$lineinfo = getLine();
break;
case "NOTE":
$note['NOTE'] = addslashes($lineinfo['rest']);
$note['NOTE'] .= getContinued();
$share->notes[] = $note;
break;
default:
$lineinfo = getLine();
break;
}
}
$moreinfo['SHARES'][] = $share;
}
else {
$lineinfo = getLine();
}
break;

"Darrin also talks about "intending to export an association" so presumably there was some earlier dialogue that discussed 'associations' and the ASSO tag, which perhaps fuelled some misunderstanding?"

Wrong presumption. No earlier dialogue, you have it all.

[tatewise]

OK, so regarding the Associated Person (ASSO ~ RELA) feature:

• Your discussions with Darrin have never mentioned that feature.
• Your recent experiments have shown that feature is NOT the solution your are looking for anyway.

So we can disregard that feature completely and focus entirely on the Shared Fact (_SHAR ~ ROLE) feature.

I am not familiar with the style of code you posted, but it seems the ROLE is copied to the NOTE of the Shared Fact.
So in your example, your Individual record in TNG gains a Death Event but its Note identifies your Role as Witness.

We all agree that is not ideal, and the task is to convince Darrin to improve TNG.
You could ask him to adjust the name of such synthetic Shared Facts to combine the Principal Fact with the Role.
So in your example, your Individual record in TNG would gain a Death-Witness fact, and identify the Principal Fact owner, i.e. your mother.

That is what Legacy does with each Shared Fact, and also lists all who share that Fact and their Role.
So it has Shared Facts such as Marriage-Witness, Death-Informant, Residence-Resident, etc.
The free version of Legacy would allow Darrin to see how that works.

Darrin can also obtain a free version of FH to see how it handles Shared Facts.

The free version of RootsMagic does not support Shared Facts but the YouTube video at https://www.youtube.com/watch?v=6q7aQi8OGLE gives a good overview and shows how the each Shared Fact offers Roles and is clearly highlighted so it cannot be mistaken for a 'principal fact' in much the same way as FH uses a blue arrow.

I believe other users of TNG are also discussing Shared Fact improvements with Darrin.
So hopefully, there may be some changes in the future.

[koalastamps]

Thanks Mike, that's a perfect summation.

[jclifford]

Just for the record, I had a long discussion with Mike on a similar topic 18 months ago (Witness role exported to TNG) and ended up with a somewhat complicated procedure which gave me what I wanted.

1. I use Mike's Export Gedcom plugin with Extra Options>Witness Role 2_SHA set to "Move to Fact Note".
This gives me a list of the witnesses in the Note including their Record IDs
2. I process the resulting gedcom file through a small Basic program which I have written which
a) converts all the witness Record IDs into clickable links (when uploaded into TNG)
b) converts the "EVEN - TYPE Role" facts for each witness into "ASSO- Rela" pairs which are clickable in
the reverse direction.
3. I upload the resulting Gedcom file into a tree on my TNG website.

So now any visitor to my website can go immediately from the Principal in any Witnessed event to each witness and vice-versa.

[mcenteno]

Wish to revive this thread and discuss about TNG and FH Event Witnesses standoff.

Apparently nothing has changed from TNG side.

The "Export Gedcom File" plugin, by Mike Tate, seems to be the a way to accomplish the task, although it might need some adjustments.

Is there anyone exporting Event Witnesses from FH to TNG and what are you doing to achieve it?

[jclifford]

I am still exporting event witnesses to TNG and still making use of the ASSO~RELA feature to do so, as I explained in my previous post to this thread. I use it mostly for Will and Probate events but also some marriages and other events.

You can see the results on my website hulbert.one-name.net. This link shows a person with links both ways:
https://hulbert.one-name.net/genealogy/ ... tree=tree1

If there were sufficient interest/demand I imagine that Mike could include the logic of my Basic routine in his Export Plugin.

[mcenteno]

jclifford, it looks nice and seems to do the job.
Would you share your program with the group?
Or better, would you share it with Mike Tate, so this might be included in his plugin, if he finds it useful?

Also would like to address Mike what I think is the main objective of Export Gedcom File plugin: to convert a FH project into other programs, even if the output file, in this particular case, might result in a non-standard GEDCOM version.

[tatewise]

I have to rely on you guys to understand what TNG does and does not do. Is the following summary essentially correct?

When TNG sees a 2 _SHAR ~ 3 ROLE structure it produces in the following effect:
The person identified by the _SHAR link gains the same Fact as the Principal.
That shared Fact is displayed chronologically with all other Facts according to its Date.
The ROLE is copied to the Note of that shared Fact. This is an important point.
So for example, an Individual gains a Death event but its Note identifies the Role of this Individual as Witness.
That is extremely close but not quite what we would all like. It should not take much to adapt it.

We all agree that is not ideal, and I believe the task is to convince Darrin Lythgoe to bring TNG in line with 7 other products that all treat 2 _SHAR ~ 3 ROLE as a de-facto standard where the ROLE modifies the shared Fact.
So taking the above example, the non-Principal gains a Death Witness event instead of just copying the Death event.
The 7 products are GedSite, Heredis, Legacy, My Family Tree, RootsMagic, TMG and Family Historian.
Heredis has recently replaced its non-standard 2 ASSO ~ 3 RELA structure to use the de-facto standard.
Many of those products have a free version in which that 2 _SHAR ~ 3 ROLE feature can be investigated.

I believe the 1 ASSO ~ 2 RELA structure is a poor substitute.
It does not allow the Fact, Date, Place, etc, to be included unless the user adds them to the RELA description.
As a consequence, they are displayed in a random order out of context with the conventional Facts.

Could we all contact Darrin Lythgoe and in our own words present the above proposal to improve TNG so it becomes aligned with those 7 other products and thus better able to support their exported GEDCOM files.

If he still refuses to consider making that improvement then I am prepared to modify the Export Gedcom File plugin.
However, you will need to accept that every 2 _SHAR ~ 3 ROLE will become 1 ASSO ~ 2 RELA structures.
There can be no exceptions for Census or Residence or any other facts.

[mcenteno]

Mike,

TNG just ignores a 2_SHAR ~ 3 ROLE structure.
It only accepts 1_SHAR ~ 2 ROLE under 0 INDI or 0 FAM.

Associations are in fact a pretty poor feature in TNG.
I'm attaching some print screens.
You can see there's an option to add a reverse association for same two people (more correctly two IDs).

Captura de ecrã 2021-02-10, às 22.48.13.png (206.34 KiB) Viewed 6311 times

Captura de ecrã 2021-02-10, às 22.49.09.png (35.25 KiB) Viewed 6311 times

Captura de ecrã 2021-02-10, às 22.49.38.png (174.63 KiB) Viewed 6311 times

[jclifford]

Mike:
I think there is something more to be said for the ASSO-RELA solution.

Most events that involve witnesses are Facts relating to a single person so using ASSO is in practice a person to person association even if not in theory, and using it to link to either the bride or groom in a marriage does not cause a problem in practice.

In FH, witnessed events are listed in the Properties pane for an individual and in some cases (especially wills) there is no indication as to whether the individual was the owner or the witness of each fact. Using ASSO in TNG removes this inconvenience.
To see the details of the witnessed fact in FH, one needs to click on the Fact line but there is no way (as far as I can see) to quickly identify the owner of the fact and look at his/her properties. In TNG, one click on the ASSO fact takes you immediately to a page showing full details of both the fact and its owner.

[tatewise]

@mcenteno: Has TNG changed the way it handles _SHAR & ROLE tags?

In the posting Re: TNG and FH event witnesses standoff ~ Mon 9th Apr 2018 koalastamps stated that with 2 _SHAR ~ 3 ROLE:

After the FH import, both my brother and I showed as dead, with our mother's death date, along with her cause of death (heat stroke).

Darrin's response was:

Hi Rod, Here's what I see:
1 DEAT
2 DATE 23 JAN 2000
2 PLAC Brisbane, Queensland, Australia
2 _SHAR @I497@
3 ROLE PRESENT
2 _SHAR @I496@
3 ROLE PRESENT
2 AGE 70y
2 CAUS heat stroke
That tells me that you've shared your mother's death event with you and your brother, which is why you're all deceased. I can't see anything that would indicate you were intending to export an association.

and then:

When TNG sees _SHAR, it thinks you want to duplicate that event for the people mentioned. If you don't want to do that, then you shouldn't use the _SHAR tag at all. TNG does associations (what most people use for witnesses) with the 1 ASSO tag, as per the GEDCOM standard.

That confirms that in 2018 TNG did recognise 2 _SHAR ~ 3 ROLE and did duplicate the 'shared' fact.
Later, koalastamps confirmed that "the ROLE is copied to the NOTE of the Shared Fact."

Can anyone please corroborate how TNG now handles 2 _SHAR ~ 3 ROLE tags in 2021.

@mcenteno: BTW ~ on the Email list you said: "In the meanwhile, I’ll try to chat with Darrin Lythgoe and see what he has to say about this issue." What was the outcome of that chat?


@jclifford: The way shared/witness facts are displayed for the non-principal depends on the Tools > Fact Types settings.
If the Role (such as Witness) is NOT specified in the Will event then FH simply replicates the Will event for the witness.
However, the Facts tab makes it very clear with a big blue arrow that it is NOT the Principal fact.
Once the Role of Witness for the Will event is defined in Tools > Fact Types then the Facts tab shared fact entry will say such as 'Will Witnessed for <testator>' or whatever the definition specifies.
( I suspect you may have imported a Will event with a Witness but not defined that Role. It is a common omission. )

Double-left-click on any such shared/witness fact and all the witness Roles are listed.
Click the 'Go To' button and you can quickly switch to any witness or the principal.

IMO the big advantage of shared/witness facts is they are shown in chronological context with all other events the person is involved with, whereas the ASSO list in TNG and FH is a random assortment out of context.

[jclifford]

Thank you, Mike, for your reference to importing.

I have a lot of witnessed events imported from Legacy into FH. They have similar witness roles defined but in slightly different syntax from the role definitions which I used when setting up the Facts in FH.

I am not sure about your reference to blue arrows - they seem to be present against witnessed facts in the properties of the Principal as well as the Witnesses, but I have not done extensive checking.

[tatewise]

It is crucial the names of the Fact definition Roles match the Roles used in the Legacy imported Facts.
You know how fussy computers are! You'd think they could work out that 'best man' is the same as 'Best-man'.

The Principal fact will have a blue or red bullet on the left, not a blue arrow, even if the Principal is also a Witness.
Don't confuse that with the 3 blue ball icon in the More column on the right, which indicates there are Witnesses.

Can you provide any feedback on the TNG use of 2 _SHAR ~ 3 ROLE tags, please?

[jclifford]

Can you provide any feedback on the TNG use of 2 _SHAR ~ 3 ROLE tags, please?

Very few of my Gedcom files seem to contain _SHAR tags but I found one to upload to TNG.

The result was that all the Event owners' individual pages showed the Event with the text from Note or Source, but no reference or link to the witnesses. All the witnesses' individual pages showed exactly the same event and text with the addition of a line "Role: xxx"; in some cases the text indicated who the Event owner was, in others this was not clear.

This link shows a page for an individual who owned a WILL event and was a witness to two other WILL events :
http://www.johnclifford.me.uk/genealogy ... I22&tree=6

This link shows an Apprenticeship event on a witness's page with no indication of who the Owner (the apprentice) was:
http://www.johnclifford.me.uk/genealogy ... 774&tree=6

[tatewise]

Thank you. That essentially confirms my summary posted on Wed 10th Feb 2021 21:21 but is better as Role: is explicitly stated.
i.e. TNG does unequivocally recognise the 2 _SHAR ~ 3 ROLE structure.

Therefore the recent statement by mcenteno must be a mistake:

TNG just ignores a 2 _SHAR ~ 3 ROLE structure.
It only accepts 1 _SHAR ~ 2 ROLE under 0 INDI or 0 FAM.

My Wed 10th Feb 2021 21:21 claim that TNG is close to being equivalent to FH and the other 6 products appears to be valid.
It seems it would not take much to make TNG shared Facts compatible and better than Associations. Do you agree?

Could we all contact Darrin Lythgoe and request those improvements as I suggested earlier?