* Witness role exported to TNG

[jclifford]

I am not sure if I understand what you mean by "TNG effectively clones the Principal Event in much the same way as the Export Gedcom File Plugin does by default". TNG does do this from a file exported from the plugin on default setting, but on the Keep tags setting:

1 WILL
2 DATE 2 AUG 1520
2 _SHAR @I1539@
3 ROLE Executor and residual heir
2 _SHAR @I1540@
3 ROLE Beneficiary grandchild
2 _SHAR @I1772@
3 ROLE Beneficiary grandchild
2 SOUR @S58@
3 PAGE Volume 2 Register 'Mathewe' 1490-1524 SW/2_357
3 DATA
4 TEXT Juliana Hurlbatt of Farnham widow. Proved 1520 Surrey Archdeaconry Court. To be buried next to husband John. Legacies to John and Will my sons children, sister Alice, John Warner son of my brother and his children and godchildren, numerous other
5 CONC sincluding 3 servants. residue and executor son William.

becomes on the witness's page (I1540):

Will 22 Apr 1520
* Role beneficiary grandchild

there is no identification of who the Principal is and the clickback is lost.

Dynamic links and collapsible dialogues sound a good idea. I hope they would provide, in descending order of priority:

Name of Principal on each Witness's page
Clickable link to Principal's page from Witness's page
Role details on each Witness's page
Clickable links from Principal's page to Witness's pages (this would also provide a list of Witnesses on the Principal's page)

[tatewise]

John, I think you misunderstand the two modes.

1) With my Plugin default settings, it exports synthetic cloned copies of the Shared/Witnessed Events but renames them by adding a prefix & suffix, and removes the _SHAR tags completely. So TNG does NOT see any Shared Events at all. What you see in TNG is what my Plugin has exported.

2) With my Plugin alternative Extra Options tab Witness Role 2 _SHA%u: set to Keep Custom Tags (LFT RMT FTA) then the it exports the _SHAR tags unchanged and does NOT copy anything. The TNG import process sees the _SHAR tags and creates cloned copies of Shared Events that you see. I plan to change my Plugin to this mode by default in the next version.

Currently, neither mode provides active hyperlinks between Principal and Witnesses.
For that 2nd option, Darrin is offering to implement dynamic links & collapsible dialogues, that you say is a good idea.
I suggest you E-mail Darrin with your suggestions, which may carry more weight as you are a TNG customer and I am not.
Hopefully, that will provide an excellent solution to the Shared/Witnessed Event scenario. QED

That leaves the problem of differentiating Principal Events from the cloned Shared Events.
Please turn your mind to the possible filtering techniques I outlined in my last posting...

[jclifford]

Thank you for the helpful explanation.

I didn't comment on filtering because I am not sure what you mean by "search" and "filtering". Do you mean applying a filter in the Export Plugin, or in TNG's import process, or when viewing a TNG page, or something else?

I have looked at witnesses in Legacy and it seems to use the same terminology, tags and synthetic events as FH, except for "Owner" instead of "Principal".

I have sent another message to Darrin as you suggested.

I said "Dynamic links and collapsible dialogues sound a good idea" but again I am not sure I understand exactly what is meant.

[tatewise]

1) The search/filter topic is related to your comment on Tue Nov 22, 2016 6:56 pm:
"the Event for the witness is now called the same as the original event, e.g. "Will", which is a bit confusing for a viewer who is expecting or trying to find the actual will of the witness him/her self"
The Shared Events each have a Note that uniquely contains the word Role:.
So when trying to distinguish the original Principal Event from the cloned Shared Events does the word Role: help?
For similar circumstances in FH, a Query could find all Will Events without a Note containing "Role:".
That would find just the Principal Will Events.
In TNG could a similar search/filter technique be employed?
I do not know what tools TNG offers and was hoping you could help.
Alternatively, do we need to ask Darrin to give the cloned Shared Events a slightly different name such as Will (Shared)?
Then there would be no confusion between the original Will event and the cloned Will (Shared) events.

2) A dynamic link is those underlined hyperlinks to other people just like you created with Associations.
A collapsible dialogue is one that expands and contracts when you click on it, like a drop-down list.
So where a Shared Event links to multiple Witnesses there would be a button below the Notes that expands & contracts the list of Principal & Witnesses, that would each be a dynamic link to their page of details.
You said "I hope they would provide, in descending order of priority:" and gave a definition of the lists, that led me to believe you fully understood the concept.

[jclifford]

1. TNG has an Advanced Search People feature which allows you to search for people using a wide variety of filters - I will try to attach an image of it - but I am not clear in what circumstances one would want to use it.

I think the cloned/synthesised events on a Witness's page should be named "Witness", or possibly "Role" but that is better as a sub-heading. This is because the existence of a link to another individual is more important to the viewer than the type of event hosting the link; this would also be consistent with FH and Legacy and possibly other programmes.

At present TNG display all the Witness events near the top of the page, named e.g. "Will" and using 2 lines each, but the individual's actual Will is one short line further down which is easy to miss (that is when the text of a will is put in the Source record - the will event is much more conspicuous if the text is in Note.)

2. Your explanation is helpful. I was not sure whether a list would include dynamic links - at the moment TNG displays no lists of witnesses.

[tatewise]

Considering the Search People dialogue, about halfway down there is the Will event.
I imagine its Fact drop-list that currently says contains can be changed to doesn't contain.
If you do that, and enter Role: in the box to the right, then click Search, does it find just the people with Principal Will events?

You say "At present TNG displays all the Witness events near the top of the page."
I disagree. It displays them in Date order amongst all the events just like FH does.
It just so happens that you have focussed on Will events.
So naturally the persons own Will is likely to come near the end of his life at the bottom of the page.
Whereas his Will Roles as Beneficiary/Trustee/Executor will come earlier in his life when he was alive.
In your screenshot there are Court events both before and after Will Role events.
If you focussed on other types of Witnessed Events you will see that Date is the key to the order.

I assume that one line Principal Will event has had its Note moved to the Source.
Whereas all the other Principal Will events have not, so the cloned Will Role copies have a copy of the Note.
If you consistently move all the Principal Will event Notes to a Source then the cloned Will Role copies would be shorter.

In these types of investigation it is important to avoid becoming too focussed on one example.
Try different types of Witnessed facts such as Baptism or Marriage.
It is also important to be consistent in the way different events are recorded.

[Shelley]

Just quickly as I'm a bit time-poor at the moment... I've written to Darrin with my two cents worth on the topic as suggested. Thanks both for being so active on this.

[jclifford]

Mike, I take your point about dates, but the Will event has not had its Note moved to the source.

The text of the will was in the source anyway because I followed your suggestion, and there never was a list of Witnesses, only a set of _SHAR/ROLE pairs of tags.

The TNG search will search for people who do not have a Will or whose Will fact contains Role but not "Does not Contain"

I have been trying to think through why I am uneasy about SharedEvents.

When FH is asked to create a witness to an event it adds a new attribute and sub-attribute to the Event in the Principal's gedcom record, i.e. level 2 and 3 tags. _SHAR is not a Custom Event tag but a custom attribute tag.

It then creates a synthetic Event for display with the Witness's data but does not add this to the Witness's gedcom record. Do you know why not?

It seems to me that it could easily be done as an ASSO/RELA pair (ASSO is an Event containing a dynamic link but not used by FH) or by a new Custom Event, say _WITN.

If that were done, then all TNG has to do is convert the _SHAR/RELA pairs into one line under the Event (or a collapsible list) containing a dynamic link to the Witness.

[tatewise]

Sorry, but you are contradicting yourself.
You say: "the Will event has not had its Note moved to the source."
Then say: "The text of the Will was in the source anyway because I followed your suggestion".
So at some time in the recent past you did move the Will event Note to its Source.
If you make the same moves for the other Will event Notes then they will all be similarly small entries.
That is what I mean about being consistent when comparing events with each other.

I don't follow when you say: "there never was a list of Witnesses, only a set of _SHAR/ROLE pairs of tags."
At the GEDCOM level the _SHAR/ROLE pairs of tags are the list of Witnesses.
In FH on Facts tab the right-click or Menu option for Witnesses lists them and Go To button links to them.
For TNG there is a proposal from Darrin (NOT implemented yet) to provide collapsible links to the list of Witnesses.

Regarding the TNG People Search, if you click on one of the drop-list boxes that currently says contains, what options are offered? i.e. click on the down arrow (ringed in red) to the right of the box.

Willcontains.png (4.73 KiB) Viewed 12599 times

FH, Legacy, Rootsweb, The Master Genealogist all implemented Shared/Witnessed Events the same way with _SHAR/ROLE tags only on the Principal Event in the GEDCOM.
FH displays a wide variety of 'synthetic' events in the Facts tab, that includes Shared/Witnessed Events, and Timeline Facts such as Birth, Marriage, Divorce, Death of many close relatives. BUT they are just display options, and nothing to do with GEDCOM. They do NOT get cloned into the GEDCOM data as that would contravene the specifications.

My Export Gedcom File Plugin, and also TNG since March 2016 , offer the ability to create cloned copies of Witnessed/Shared Events and remove the _SHAR/ROLE tags. My Plugin includes a textual list of Witnesses in the Note of each cloned fact (which you don't like). Darrin is proposing a collapsible list of Witness links below the Note of each cloned fact (which is better than my Plugin could do).

ASSO is NOT an Event tag, no more than NAME, FAMS, FAMC, OBJE, or NOTE are Event tags. None of them allow Event sub-tags such as DATE, PLAC, AGE, ADDR, etc.
BTW: FH does fully support the ASSO/RELA tags, by default only via the All tab, but they can be customised into other tabs; see fhugdownloads:contents:property_box_tabs_associated_persons|> Property Box Tabs: Associated Persons. TNG also supports the ASSO/RELA tags, but many products do not.

At the end you say: "... or by a new Custom Event, say _WITN. If that were done, then all TNG has to do is convert the _SHAR/ROLE pairs into one line under the Event (or a collapsible list) containing a dynamic link to the Witness." Effectively, that is what we are requesting TNG should do automatically when it imports _SHAR/ROLE tags. The collapsible dynamic link list is already being offered by Darrin. We just need to work on him for the synthetic cloned custom event feature.

[jclifford]

Mike, please calm down. I will explain what I meant by all the things which have annoyed you if you wish but I am not sure that it is a good use of this Forum.

I would just welcome an explanation of why "They do NOT get cloned into the GEDCOM data as that would contravene the specifications".

There are dozens of Custom Events and Tags which various pieces of software have invented and other programmes regularly use. The FHUG Knowledge Base lists 32 of them used by FH, and some of them are at level 1. Why are all these acceptable but a simple 1 _WITN tag would not be?

[tatewise]

There is a big GEDCOM distinction between Custom Events and User-defined Tags.

Custom Events are a standard part of the specification and are introduced by the 1 EVEN tag followed by the 2 TYPE tag to define the name of the Event. FH does extend this with the 1 _ATTR tag to define Custom Attributes in the same way.

User-defined Tags must start with an underscore and the FH ones are listed in glossary:gedcom_extension_list|> GEDCOM Extension List but none of them are Events.

What would a 1 _WITN tag achieve?
What would its subsidiary tags be?
How would it be related to the Principal Fact?
How would it cope with a multitude of different types of Principal Facts? (Will, Probate, etc...)
Anyway, it is unlikely to ever happen, so lets focus on what is likely by influencing Darrin.

[jclifford]

There seems to be a very fine distinction between Attributes and Events. For instance FH classes Education and Military Service as Attributes but Imprisonment as an Event. So I am happy to use Attribute instead of Event - They are both Facts for FH, except ASSO for some mysterious reason.

What would a 1 _WITN tag achieve? The same as an ASSO tag
What would its subsidiary tags be? ROLE
How would it be related to the Principal Fact? It would contain a dynamic link to the Princpal, not to the Fact (the same as ASSO does)
How would it cope with a multitude of different types of Principal Facts? by specifying the role as the content of the ROLE tag.

BTW: FH does fully support the ASSO/RELA tags, by default only via the All tab, but they can be customised into other tabs; see Knowledge Base > Property Box Tabs: Associated Persons. TNG also supports the ASSO/RELA tags, but many products do not.

I tried following your link but it took me to a page without a heading with installation instructions for "This" in FH v4 and v5.

I also tried opening a gedcom file in FH containing ASSO tags but it produced an Exception Report with them all marked as "INFO ONLY: Loaded uncategorised data (non-GEDCOM)" and I could not find where the data had been loaded - nothing on the All tab of the relevant individuals.

[AdrianBruce]

There seems to be a very fine distinction between Attributes and Events. For instance FH classes Education and Military Service as Attributes but Imprisonment as an Event. So I am happy to use Attribute instead of Event - They are both Facts for FH, except ASSO for some mysterious reason. ...

Excuse me adding my thoughts here but I've had occasion in the past to butt my head against GEDCOM.

Re the "very fine distinction between Attributes and Events". It's a very fine line in the real world but in FH it's actually quite clear. Attributes have values in the Facts tab for an Individual and Events don't.

Nor is the difference from an ASSO mysterious. Well, not to me. In the GEDCOM specification INDIVIDUAL_EVENT_STRUCTURE, and INDIVIDUAL_ATTRIBUTE_STRUCTURE are both one level "down" from the Individual - so they are both normally level 1. Further, when you look at the definition of Attribute, it very rapidly turns into something with the same subsidiary items as Events.

ASSOCIATION_STRUCTURE is also one level "down" from the Individual, along with PERSONAL_NAME_STRUCTURE, SEX, CHILD_TO_FAMILY_LINK and a number of other items. ASSO is therefore on a level with Events and Attributes, not under them, and its subsidiary items have pretty much zero commonality with Events and Attributes.

Again, I would emphasise that's not a real world analysis, it's an analysis of the GEDCOM, done simply to explain why FH happens to have chosen the classifications that it did. (In a real world, for instance, wouldn't a Name be an Attribute? And yes, there is a reason I chose that example - nothing to do with FH though).

[jclifford]

I understand what you are saying Adrian, but FH classes both Events and Attributes as Facts (and synthetic events) so I do not see why it does not also class ASSO as a Fact about the individual and show it/allow it to be created on the Facts tab - at least it is a real Fact and. as you say, in the gedcom file at level 1.

[tatewise]

As Adrian says GEDCOM & FH make the distinction between Event and Attribute very clear.
Attributes such as Occupation and Education have a Value to define the Occupation or Education. That Value is held in the box next to the fact name in the Facts tab, and on the same line as the 1 OCCU or 1 EDUC tag in the GEDCOM.
Events don't have such a Value nor associated box, and don't allow anything after their GEDCOM tag.
However, that is the only difference betwen them.
GEDCOM specifically defines NAME, ASSO, etc, as NOT being Events/Attributes because they do NOT have the necessary subsidiary tags of DATE, AGE, PLAC, ADDR, NOTE, etc, but do have subsidiary tags such as GIVN and RELA, etc, which are invalid for Events/Attributes. Those terms such as Events and Attributes have very formal definitions in GEDCOM that may not be the same as their normal English language meaning. It is that formality that allows GEDCOM files to be exchanged between products, at least for the core tags and structures. It is all the user-defined add-ons that upset things, such as _SHAR Witnesses.

If 1 _WITN only has a 2 ROLE tag then that would NOT identify the Principal Fact, as many different Facts could all have the same ROLE name. e.g. ROLE of Witness for Birth, Marriage, Will, etc.
So how is the correct Fact identified, and bear in mind that there could be several instances of the same Fact, such as multiple Marriages, but the Witness in question only applies to one of them?
What would be displyed in the Witness person's page of details for the 1 _WITN tag?
It seems to me that it offers no more than the 1 ASSO & 2 RELA tags already provide.

Sometimes links such as fhugdownloads:contents:property_box_tabs_associated_persons|> Property Box Tabs: Associated Persons do not open at the top of the page, so just scroll up to the top. Then follow the V5+ instructions to get a custom Assoc tab as illustrated.

You obviously did not add the 1 ASSO tag correctly by hand. FH said it had loaded uncategorised data (UDF), so it will be there with a star bullet. Did you expand all the [+] buttons on the All tab to reveal all levels, and scroll down to the bottom because UDF are listed last?
To add an ASSOciated person in FH, on the All tab use right-click Add Miscellaneous > Add Associated Person > Add Link to New/Existing Individual Record. Then click on its [+] to reveal the Relationship field, which in GEDCOM should look like:
0 @I1@ INDI
1 NAME John /Smith/
1 ASSO @I2@
2 TYPE INDI
2 RELA Friend

[jclifford]

More apologies to you Mike, and to Adrian.

When I said that I had tried importing a file with ASSO tags into FH, the tags were at level 2. I have now tried with level 1 tags and they do show on the All tab as you said. And I have discovered how to create an ASSO in FH.

[jclifford]

What I wrote was:

"It seems to me that it could easily be done as an ASSO/RELA pair (ASSO is an Event containing a dynamic link but not used by FH) or by a new Custom Event, say _WITN".

So I was wrong to refer to ASSO as an Event and to say it was not used by FH, but I have never suggested that a new tag like 1 _WITN would offer more than ASSO (although it might have a DATE tag which would be useful). I suggested it because there seemed to be some problem with using ASSO for witnesses.

Witnesses seem to have been introduced by Roots Magic in 2008 (or earlier in some other software?) . Now Legacy has had them for 2 years and FH for one year and several of their competitors are no longer with us, it seems to me a good time to implement the concept in a more effective way in gedcom terms.

[tatewise]

RootsMagic, Legacy, FH V6 since Dec 2014, the defunct TMG, (and similarly Heredis) all implement Witnesses effectively the same way, so you will have an uphill battle to get them all to change. I think your efforts would be more fruitful in a different direction.

[jclifford]

I am sure you are right, although I would still like to know why witnesses were implemented in such a lopsided way in the first place.

It would surely be far easier to put an ASSO or _WITN tag/event/thing in the witness's record when creating the _SHAR attribute in the Principal's record than to do it later via a Plugin or anything else.

For my current research, focussed on the early 16th century, witnesses in wills, property transactions, court and manorial records are the only way to put together families.

[tatewise]

You will have to ask the developers of RootsMagic, Legacy, TMG, and FH that implementation question.

Regarding the TNG People Search, if you click on one of the drop-list boxes that currently says contains, what options are offered? i.e. click on the down arrow (ringed in red) to the right of the box.

contains.png (5.16 KiB) Viewed 12533 times

[jclifford]

As I tried to imply earlier, the box contains:
exists (i.e. the Fact Will does exist)
does not exist
contains
equals
starts with
ends with

and also
soundex of
metaphone of

but not
does not contain

[tatewise]

OK John, thank you.

[tatewise]

Darrin tells me there is also a Notes page Search facility in TNG.
Could that be used to find Will facts with or without "Role:" in the Note?

[jclifford]

In the Advanced Search it appears that you can search for "Note contains Role:" AND "Will Exists" but I get no results - with or without specifying a surname. I get results if I search for Birth Place, but no results for Baptism Place.

I don't understand what is going on.

[tatewise]

Sorry, I do not subscribe to TNG, so cannot help.
You will just have to experiment more, or dare I say read the Help.