Family Historian User Group

Hi Mike!

Hoping you can help me with your 'Export Gedcom File' plugin.

Family Historian and TNG have a different interpretation of GEDCOM witnessed events.

This is an example from TNG:

1 ASSO @I496
2 TYPE INDI
2 RELA Witness

And FH:

2 _SHAR @I496@
3 ROLE Witness

I have corresponded with them and each say their interpretation is correct and so nothing will be changed on either side of the fence.

Really unbelievable stance that both parties are taking...

Mike, can you come to the rescue, so that I can import my witnesses from FH into TNG.

Many thanks,
Rod

Welcome to the FHUG Rod. I am afraid you are mistaken.

TNG supports Fact Witnesses with the 2 _SHAR tag exactly the same as FH.
See plugins:help:export_gedcom_file:tng_the_next_generation|> Export Gedcom File ~ (TNG) The Next Generation.
The default TNG options in the Export Gedcom File Plugin keeps the 2 _SHAR tags.
But bear in mind it is NOT a standard GEDCOM feature and so is only supported by a few products.

The Associated Person with the 1 ASSO tag is a standard GEDCOM feature also supported by both TNG and FH.

What made you think Fact Witnesses with the 2 _SHAR tag were not supported by TNG?

I am surprised that the response from TNG did not make that clear, but maybe depends on how you asked the question.

Hi Mike, this is from TNG:

"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 is, I have witnesses set up in FH, These are exported to GEDCOM with the _SHAR tag. Darrin from TNG says he interprets the _SHAR tag as sharing the same event, not witnessing the event.

For example, I have myself as a witness to my mother's death in FH. Upon importing the FH GEDCOM to my TNG website, I show up as having died on my mother's death date!

Thanks, Rod

I have to admit I am not a TNG user, so must rely on others for how to deal with such issues.
That handling of Fact Witnesses ~ 2 _SHAR tags by TNG has not to my recollection been raised as a concern before.
However, it is a side effect of using non-standard GEDCOM that has no agreed semantic meaning across products.

Could any other TNG users please offer their advice on this topic?

Rod, you could try the Plugin Extra Options tab Witness Role 2 _SHA%u: setting of Move to Fact Note.
That creates a synthetic custom Fact for each Witness with all the Roles in the Note field.
So in your example, you would gain a Ω Death Role event with a Note listing your mother as Principal and yourself as Witness (or whatever Role you have assigned).

It would be complex to 'morph' 2 _SHAR tags into 1 ASSO tags for several reasons.
Using your example:

1. 1 ASSO would only apply to your mother's record, unless there was also a reverse 1 ASSO in your record.
2. All Principal Fact details such as the fact Name, Date, Place, Address, etc, would have to be included as labelled Notes in the Note field and repeated in the 1 ASSO tags of every Witness.
3. Any Source Citations on the Principal Fact would have to be repeated on each 1 ASSO tag.

BTW:
This whole topic highlights what has been discussed elsewhere regarding the semantics of Fact Witnesses.
In your example, were you really a Witness, or actually the Informant who registered the Death Certificate.
Many users believe that is an important distinction, and that a custom Death Registration event should be recorded separately from the Death Event, with a different Date, Place, etc.

Mike it's simple. I was at my mother's hospital death bed and watched her die. I was a witness to her death.

If I was in the same household on census night I would consider that as sharing the event.

TNG is correctly managing the difference between a shared event and a witnessed event.

There is a distinct difference and right now it appears to me that FH is treating witnessed events as shared events.

Oh well, thanks for considering this anyway Mike.

Hopefully FH will read all this, realise their mistake and correct the code.

As I said, it is down to semantics for a non-standard GEDCOM feature.

Can you please explain in more detail how:
"TNG is correctly managing the difference between a shared event and a witnessed event."
I don't understand how the 1 ASSO example from TNG can represent an event, or is it done another way?
Precisely how would you expect the code in FH to be corrected to represent both shared and witnessed events?

FH caters for both shared and witnessed events via its Tools > Fact Types definitions.
The template wording for the Principal and each Role allows both to be reflected in Facts tab and Narrative Reports.

Progress, I think Let me look further into how FH uses the role to make the distinction between shared and witnessed events, and importantly, if the correct GEDCOM syntax is used for witness events.

Mike, it's nothing to do with semantics, or narrative reports (these are fine) and everything to do with FH not producing the correct GEDCOM syntax for witnessed events.

As expected, I couldn't find anything in Help which mentions using specific roles for shared events (and which would produce different GEDCOM). Everything is about witnesses.

There needs to be a distinction in FH to handle both.

For example, when right clicking on an event, the option is there to add 'Witnesses...', however, to repeat, the associated GEDCOM code needs to be corrected.

Then there could be another option on the same menu for say, 'Participants...', those that shared in the same event, and the GEDCOM could then be appropriately coded.

I'm just highlighting that this bug should be dead and buried and not me.

Sorry, but you have still given no definitive explanation of how TNG handles things nor how you expect FH to be corrected.
Please explain exactly what valid GEDCOM syntax structures would resolve the problem for you.

Mike, I'm not here to have this debate with you. I've now reported the problem again to FH and awaiting a response.

You've already indicated in an earlier post it was too difficult to change your plugin to output gedcom for witnessed events correctly, as TNG expects.

It's important to remember, _SHAR is a custom item, therefore FH is exporting it correctly for FH. The problem is TNG is not taking the role into account when importing it, so it looks as if the people linked to the Death are also Dead.

The simplest solution might be to simply remove the Witnesses on all events when exporting to TNG, or ask Darrin nicely if it's possible to take account of the Role when importing to TNG.

Or as Mike has already suggested. Use the "Plugin Extra Options tab Witness Role 2 _SHA%u: setting of Move to Fact Note." which will avoid the problem.

<deep sigh> I give up.

Just want the BUG fixed in FH which is using a _SHAR custom event instead of the ASSO which is what is meant to be used in this case.

NO it's not "Associations" could be used in some cases, but they require the information on the "Witness" and not the Fact owner, the way FH uses _SHAR is more flexible and bi-directional, meaning you can get the information included in the sentences for the fact owner, something which would only happen where the information was repeated in both the owner and the witness.

If you really want to use a standard GEDcom ASSO tag as per http://wiki-en.genealogy.net/GEDCOM/ASSO-Tag:

Although not usually the best approach, there is another way to record these relationships which is to create an association between the two people. You can do this in the All tab of the Property Box. Right-click on the first person's record (first row in the All tab) and then, from the dropdown menu that appears, choose Add Miscellaneous, and then Add Associated Person. You will be able to document the nature of the relationship in the Relationship subfield.

(From the FH Help file).

Looking at the import logic for TNG, it does include in the Note the Role recorded so I suspect if you look the information will show the Role in the Note and as far as I can see it does not update the Death date for the record, but I may have missed it.

It also includes the NOTE if set against the Witness. I can't remember if the Witness sentence can be obtained in a plugin though.

I wonder why Darrin is disinterested in accommodating the non-standard _SHAR invented by FH? He has stated that FH should be using the industry accepted ASSO and that is what his software supports.

[EDIT: SHAR corrected to ASSO.]

Somebody more knowledgeable than me will no doubt be along to correct me soon, but I believe Gedcom has no standard SHAR tag.

Other product may define the same (non-standard) SHAR tag but FH takes the approach that all non-standard tags should be denoted as such (with a leading _ as per the Gedcom standard. See http://wiki-en.genealogy.net/GEDCOM/_UserDef-Tag ). I'm not aware of any documentation for the 'industry-standard' non-Gedcom compliant SHAR tag?

However, I doubt you care about the nuts and bolts -- you just want a solution for your data export needs. As TNG isn't going to be changed, and I very much doubt Calico Pie will abandon Gedcom compliance, you would be best advised to explore the options already described here.

Neither _SHAR nor SHAR is an "industry standard" GEDCOM feature.
Can you supply a reference to the standards documentation for SHAR please.
But _SHAR is a valid user-defined GEDCOM extension, whereas SHAR is an illegal GEDCOM tag.
Perhaps you meant to say ASSO instead of SHAR?

FH did not invent _SHAR but replicated the "de facto" feature from The Master Genealogist and Legacy and RootsMagic that all support _SHAR in the same way. So it is NOT a bug.

As has been said before, the Associated Person (ASSO) feature is standard GEDCOM but cannot support all the necessary data associated with witnessing a fact. Taking your example, how would it associate you with your mother's Death event?

If Darrin can supply the technical details of the format for the SHAR tag, then I can modify the Export Gedcom File Plugin to convert the FH _SHAR feature into the TNG SHAR feature.

Yes, typo thanks Mike, meant ASSO.

This is an example gedcom that FH produces:

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

This is what TNG expects:

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)

"TNG currently doesn't care about the TYPE line (although it should). So you can put it there if you want, but it's not needed at the moment." (quote, Darrin L)

As we keep saying, but you are not listening, FH supports the Associated Person ASSO feature the same as TNG.
So why don't you just use that standard ASSO feature in FH instead of _SHAR that you say is unsuitable?
Then presumably it will import into TNG exactly as you require. That is the SOLUTION.

That is what the GEDCOM standard is for - to allow products to communicate using identical features, without having to negotiate. So no more huffing and puffing is needed, just use the Associated Person ASSO feature in both products.

If you cannot locate the Associated Person ASSO feature in FH, look on the All tab, right-click Add Miscellaneous > Add Associated Person then right-click on Associated Person to add Relationship, Notes and Sources.
See also fhugdownloads:contents:property_box_tabs_associated_persons|> Property Box Tabs: Associated Persons.

Mike, I am not going to rekey the hundreds of witnesses I have in FH. I like the witness support within the product itself.

I had the impression from your last post that you were now willing to mod your plugin to accommodate what TNG expects.

So be it. Let the problem remain. Instead I will use another genealogy product that will work with TNG.

Good luck with another product! Let us know how you get on.
I would wager you have exactly the same problems.

You can't have it both ways.
You now say you like the FH Fact Witness feature, that earlier you said had a BUG that needed correcting.

You also differentiated between Shared Fact and Fact Witness.
How many of those two do you have?
Presumably only one of those types need changing to ASSO to match TNG?
You could make the changes with a Plugin.

With that in mind, what data item from the _SHAR feature would be used in the ASSO Relationship?
Are you suggesting that the ROLE value (Witness in the example) is copied to the RELA value?
i.e. effectively you want
2 _SHAR @I496@
3 ROLE Witness
converted to
1 ASSO @I496
2 TYPE INDI
2 RELA Witness
but in that case there is nothing in the ASSO ~ RELA values that ties it to the Death Event.

It appears that way, but Darrin is handling it, not me. I'm just a boring old user, not a software developer. Please have this conversation with him.

Rod,

Mike (and others) are trying to be helpful, but I at least am getting confused about what you actually want.

Going back to your first post, it seems you want to use the ASSO tag, so that TNG can handle it without any changes.

This is an example from TNG:

1 ASSO @I496
2 TYPE INDI
2 RELA Witness

and later

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)

However, within the Gedcom standard, the ASSO tag can only be used within an individual data structure, not an event structure -- it associates individuals with individuals, not individuals with events. You are allowed to have an extension tag _ASSO for an event (but not ASSO). (See discussion at GEDCOM Criticisms (12504)

Some products seem to have adopted a non-standard use of ASSO, where FH has adopted the non-standard _SHAR tag. There's no right or wrong here, nor bugs, just two products that have implemented non-gedcom standard features in different ways.

If you can clarify exactly what TNG is doing/expects, it might be possible to change your existing uses of Witnessed events into whatever TNG expects as a one-off process or handle it repeatedly in the export.

But whichever it is, there needs to be an accurate spec to work with (and preferably one that will be of value to multiple users).

I'm just a boring old user, not a software developer. Please have this conversation with him.

We're just boring old users as well. With the best will in the world, why should any of us have a discussion with him about something that is a problem for you?