* Importing from 'Generations'

[Paul Wigan]

When assigning GEDCOM Tags it would be wise to use 5 or 6 capital letters to avoid any risk of accidentally using one of the 4 letter Standard GEDCOM tags, except where you do want the Generations item to become a Standard GEDCOM Event.

Hi Mike

I haven't experimented too much with Gedcom tags in Generations so, for example, I do not know if a three character tag will work.

However, we cannot use your suggestion as Generations will not allow Gedcom tags of more than four characters. It will also only allow capital letters, as letters appear in capitals as you type even if the caps lock is turned off. It does seem to allow numbers and characters to be typed into the Gedcom tag field, although I again have no idea if those will work in practice.

I have found a schedule of standard Gedcom tags in GenWiki :-

http://wiki-en.genealogy.net/GEDCOM-Tag ... 20families

I think that I should be OK if I create four character Gedcom tags but avoiding anything on that schedule. Do you agree ?

Many thanks.

Paul

[Paul Wigan]

I think that I should be OK if I create four character Gedcom tags but avoiding anything on that schedule. Do you agree ?

Hello again Mike

An added complication is that there seem to be preset Gedcom tags in Generations that do not appear on that schedule. Two quick examples are :-

Citizenship = CITN
Land Purchase = PURC

So I will need to avoid such Generations specific tags as well.

It would have been useful to be able to extract a schedule of all Gedcom tags used in Generations, but such functionality does not seem to exist.

Thanks.

Paul

[tatewise]

I concur with everything you have proposed.
The list of GEDCOM tags you found is comprehensive, and the Fact tags are just a subset, but if you avoid all of those tags then you will be safe. Valid GEDCOM tags can be composed of only capital letters, digits, and underscore.

There are a great many Generations GEDCOM tags that are not on that schedule
That is why we are having so much trouble importing the GEDCOM into FH.
They include all those fact UDF tags.

[Paul Wigan]

Hello Mike

An update and a couple of questions please.

Having defined those Gedcom tags in Generations and created a new Gedcom file, I have followed your methodology carefully and appear to have successfully imported it into FH. I say "appear" as I will confirm that tomorrow after a side-by-side visual check with Generations.

The UDF list had an extra 1,300 items compared to the UDF list generated from the "old" Gedcom import. Hence, I assume that means that the tagging that I did earlier identified an additional 1,300 events or attributes - or parts of events or attributes - that had not featured in the previous Gedcom file.

The only problem I encountered in this process relates to my final eight UDF items, which are actually two events. These are individuals who got divorced and the divorces were entered as individual rather than family events in Generations. Trying to create a Fact Type for Divorce with a Record Type of Individual prompted the following error message :-

Screenshot 2022-03-26 174555.jpg (35.41 KiB) Viewed 4901 times

Any thoughts as to how we move forward on that one please ?

You have also mentioned previously a method of discovering further "lost" notes in the Gedcom. Have we effectively now covered that or is there are further process that we can now embark on please ?

Many thanks.

Paul

[tatewise]

Since there are only two events, I suspect it will be easier to delete those two Individual 'Divorce' UDF and manually create a standard Family Divorce fact for the couple as I mentioned earlier.
( I assume the two UDF are for the two people who were divorced. )

The things you referred to as missing were all those Events, Facts, Notes without GEDCOM Tags, that become Facts in FH.
So unless you discover something else that is missing we seem to have found them all.

[Paul Wigan]

Since there are only two events, I suspect it will be easier to delete those two Individual 'Divorce' UDF and manually create a standard Family Divorce fact for the couple as I mentioned earlier.
( I assume the two UDF are for the two people who were divorced. )

The things you referred to as missing were all those Events, Facts, Notes without GEDCOM Tags, that become Facts in FH.
So unless you discover something else that is missing we seem to have found them all.

Hi Mike and thanks for that.

I can easily deal with that Divorce point manually. They are not a couple who divorced ; they are two different individuals on different fringes of the dataset in question. They divorced their partners without issue, and hence I have taken the decision to curtail my records at that point.

I posed the question as it could be relevant when I tackle my other datasets. However, let's leave it now and if the situation does actually arise, I will ask again.

The other thing that I haven't done, and you have mentioned this in passing previously, is anything around "Inline Sources for Notes". I'm note sure that I understand the knowledgebase entry on this :-

>> Inline Sources for Notes
>> These are not supported for ƒh, but you can keep the sources to the complete note, by changing the level of the Note field to 1 rather than 2. Ask in the Forums if unsure how to achieve this.

What is that all about please ? And is it something that I need concern myself with ?

Best wishes.

Paul

[tatewise]

Since there have been no UDF associated with Source Citations I suspect you don't have that problem, so let us assume you can bypass that advice. That is not surprising since none of your screenshots has shown any evidence of any Source Citations at all.

[tatewise]

If you want to keep the Divorce fact against the Individuals instead of using the Family Divorce fact, then create a custom Individual Divorce fact, ignore the warning, and say OK to Proceed anyway? The Family and Individual facts will be distinct from each other. If any of your Individual Divorce facts have a 'value' like many of your facts, then create a custom Individual Divorce Attribute, e.g. if you put the divorced spouse as the 'value'. Otherwise, create a custom Individual Divorce Event.

[Paul Wigan]

Hello Mike

I've spent most of the day assigning Gedcom tags, exporting. importing and the like on various different datasets. This seems to have been successful, although I have a good deal more visual checking to do.

However, I have hit two problems involving data arriving in FH, but with FH not necessarily dealing with it as intended. I am hoping that these problems can be dealt with in FH, and would welcome your help please.

My UDF list is empty. But I have a problem with three Probate entries appearing thus :-

1.jpg (7.83 KiB) Viewed 4811 times

The note that I want to appear is then found in the Note Records :-

2.jpg (59.93 KiB) Viewed 4811 times

So how do I move those three notes please ?

The other problems that I have experienced involves former UDF Tags appearing as follows :-

3.jpg (16.03 KiB) Viewed 4811 times

In that case, how do I get "1st wedding - Yes" but dispense with the "LICE UDF Tag=" prefix please ?

I am really sorry if we have covered either of these points and I am now overlooking the advice given. Any help that you can offer on these points would be greatly appreciated.

Many thanks.

Paul

[tatewise]

Probate
Since there are only three facts, they can be fixed manually...

Copy & Paste the date part of the Note Text into the Date box of the Probate fact on the Facts tab of the Property Box.
Copy & Paste the remainder of the Note Text into the Note box of the Probate fact on the Facts tab of the Property Box.
Delete the Note item shown in your screenshot that refers to @N9@.
Delete the Note Record whose content has all been copied to the Probate fact.

Repeat that process for the other two facts.

Licence
The problem is caused by the Licence fact being created as an Event instead of an Attribute.
So there is nowhere for the Change Any Fact Tag plugin to put the 'value' 1st wedding - Yes.
Therefore the plugin saves that 'value' in the Source Note.

If you are happy for the Licence fact to remain an Event and there aren't too many of them, then Copy & Paste the text following LICE UDF Tag= into the Note box of the Licence fact on the Facts tab of the Property Box, then delete the Source Note item.
If there are too many to handle manually then I can provide a plugin.

If you prefer the Licence fact to be an Attribute then ask how to achieve that and I will explain.

BTW: It is worth checking the results of Change Any Fact Tag (or any other plugin) before closing FH.
If anything is unsatisfactory then Edit > Undo Plugin Changes will reverse the plugin changes.
Then you can ask for advice.

[Paul Wigan]

Probate
Since there are only three facts, they can be fixed manually...

Copy & Paste the date part of the Note Text into the Date box of the Probate fact on the Facts tab of the Property Box.
Copy & Paste the remainder of the Note Text into the Note box of the Probate fact on the Facts tab of the Property Box.
Delete the Note item shown in your screenshot that refers to @N9@.
Delete the Note Record whose content has all been copied to the Probate fact.

Repeat that process for the other two facts.

Hello Mike and thanks for that.

I can correct those three facts manually, but at a convenient time, please either :-

1. explain how to avoid this problem arising in the first place, or

2. demonstrate how to correct the problem automatically.

Whilst there are only three examples of this in the dataset of 80-odd individuals that I am addressing now, I am also looking ahead to importing far larger datasets in the near future.

Many thanks.

Paul

[Paul Wigan]

Licence
The problem is caused by the Licence fact being created as an Event instead of an Attribute.
So there is nowhere for the Change Any Fact Tag plugin to put the 'value' 1st wedding - Yes.
Therefore the plugin saves that 'value' in the Source Note.

If you are happy for the Licence fact to remain an Event and there aren't too many of them, then Copy & Paste the text following LICE UDF Tag= into the Note box of the Licence fact on the Facts tab of the Property Box, then delete the Source Note item.
If there are too many to handle manually then I can provide a plugin.

If you prefer the Licence fact to be an Attribute then ask how to achieve that and I will explain.

Hello Mike and thanks for that.

We actually have two situations in which the UDF tag is appearing in this way, these being Licences and Banns.

I imagine that a Licence could be an Event and it could be an Attribute. I would consider it an Attribute if it has an enduring value such as a pilot's licence ; but it is an Event if it is more one-off in nature such as the grant of a licence to marry.

If we take the licences and the banns together in this dataset, there are nine examples that would require manual amendment, so that is reasonable.

However, I would appreciate your view please as to how we avoid or deal with these when I am dealing with my larger datasets. Is it reasonable for them to remain Events and be corrected by plugin ; or is it preferable that I change them to Attributes ?

Many thanks.

Paul

[tatewise]

Strictly speaking, your definitions of Attribute versus Event are absolutely correct.
From a practical standpoint, the only difference is that an Attribute can have a 'value'.
If you change Licence and Banns to be Attributes then the Change Any Fact Tag plugin will migrate the 'value' in the same way as all the other facts you have imported. Otherwise, I suggest you learn how to write plugins to make the corrections needed.

Having captured all the facts and values, if you still felt strongly about some facts being Events rather than Attributes then they can be changed later with appropriate plugins.

To change Events into Attributes, first use Tools > Fact Types... to define an Attribute with the same Name, and ignore the warning about duplicated Names.
Then Edit... the Event and change its Label to include the word Event, e.g. Licence Event.
In Change Any Fact Tag it is then easy to differentiate the Event from the Attribute and convert from one to the other.
That won't move the Source Note: 'value' which must be done by hand for the few facts in this dataset.
Finally, you can delete the Tools > Fact Types... Event definition.

[KFN]

My comment is probably not welcome (sorry) but I consider all licenses obtained by a individual as a source for an event for obtaining said license. I realize that it sound like I’m splitting hairs, but in the case of a Family event MARL (marriage license) this event for me sets the standard for all other licenses obtained. Therefore an EVEN tag with a TYPE of <licensed name>, maybe “licensed pilot”.

[tatewise]

KFN, you are not wrong, but the primary aim of this thread is to import the Generations datasets into FH retaining as much data as possible. That involves some compromises that may be rectified later. I suspect Paul will be most comfortable initially with the FH facts being similar to the Generations facts.

I have a number of suggestions at the back of my mind along the lines you have proposed but converting INDI.LICE UDF into Family Event facts is not straightforward when it is not certain which Family couple (if any) is involved.

Migrating all the fact data from all Paul's Generations datasets into FH Projects is the first step.

[Paul Wigan]

Good evening Mike and Ken

I think that it is fair to say that my objective is to safely and accurately move all of my data from Generations from FH, and to import it into FH in a format that will facilitate a subsequent tidying-up exercise. It is a job that I should have undertaken some time ago, but inertia convinced me to remain with a package that is clearly well past its sell-by date.

I am having an evening doing one or two other things ; my project will resume tomorrow evening !

Take care.

Paul

[Paul Wigan]

Probate
Since there are only three facts, they can be fixed manually...

Copy & Paste the date part of the Note Text into the Date box of the Probate fact on the Facts tab of the Property Box.
Copy & Paste the remainder of the Note Text into the Note box of the Probate fact on the Facts tab of the Property Box.
Delete the Note item shown in your screenshot that refers to @N9@.
Delete the Note Record whose content has all been copied to the Probate fact.

Repeat that process for the other two facts.

Hello Mike and thanks for that.

I can correct those three facts manually, but at a convenient time, please either :-

1. explain how to avoid this problem arising in the first place, or

2. demonstrate how to correct the problem automatically.

Whilst there are only three examples of this in the dataset of 80-odd individuals that I am addressing now, I am also looking ahead to importing far larger datasets in the near future.

Many thanks.

Paul

Hello Mike

I think that I am growing in confidence when exporting and importing datasets, and for the moment, I seem to have got those Events and Attributes sorted out.

I would appreciate your thoughts on the probate matter above. I have manually corrected the three examples in the dataset that I was working on a couple of days ago, but I would like to try to avoid this problem as I begin to import some far larger datasets.

Many thanks.

Paul

[tatewise]

To automate that process will need a plugin. As I think I've said before, it would have been better not to manually fix those three, so we could use them to prove that a new plugin design works correctly. Now I will be working 'blind' until some examples appear in another dataset.

There might be an alternative solution, but I need to see a snippet of GEDCOM exported by Generations for those Probate (PROB) facts with the subsidiary NOTE tag. Could you provide such a snippet please.

[Paul Wigan]

Hello Mike

I am pleased to say that you won't need to work "blind". For practice, I have actually imported that dataset into FH twice, but as two different projects with two different names. I have manually corrected the probate problem in one of those projects, but have kept the errors in place on the other.

The Gedcom is :-

0 @N9@ NOTE
1 CONC 20 Feb 1873. Administration of the effects of Elizabeth Frift
1 CONC was granted to George Love Frift. Son and one of the next of
1 CONC kin. Effects under £200.
0 @N10@ NOTE
1 CONC 27 Feb 1873. Administration of the effects of William Banfield
1 CONC Gallway Frift was granted to George Love Frift. Brother and one
1 CONC of the next of kin.Effects under £1,000
0 @N11@ NOTE
1 CONC 7 Jun 1882. The Will of George Love Frift was proved by Louisa
1 CONC Elizabeth Frift. Spinster ,the daughter , the sole executrix.
1 CONC Personal Estate £2,251

Meanwhile, the Notes appear in FH as :-

Screenshot 2022-03-30 202525.jpg (107.92 KiB) Viewed 4637 times

Is that what you need to have a think about this ?

Many thanks.

Paul

[tatewise]

NO, I need the Probate fact like this:
0 @I321@ INDI
: : : : : :
1 PROB
2 NOTE @N9@
as exported in GEDCOM by Generations not what it looks like in FH after import.

[Paul Wigan]

Hello Mike and thanks for that

This is one individual :-

0 @I2@ INDI
1 NAME Elizabeth /BANFIELD/
1 SEX F
1 ADDR Elizabeth BANFIELD
2 CONT (1841) - Leicester Square
2 CONT St Anne Soho
2 CONT Westminster
1 BIRT
2 DATE 1789
2 PLAC St Anthony Cornwall
1 DEAT
2 DATE 8 JUL 1869
2 PLAC Harrow on the Hill
1 RESI
2 DATE 1851
2 PLAC 12 Villiers Street St Martin in the Fields Westminster Middlesex
1 RESI
2 DATE 1861
2 PLAC Harrow Heath Middlesex
1 OCCU 1841 - Housekeeper
1 NOTE @N7@
1 PROB @N9@
1 FAMS @F1@
1 FAMS @F2@
1 CHAN
2 DATE 8 OCT 2012

Is that what you require please ?

Thanks.

Paul

[Paul Wigan]

Events ~ Probate Notes ~ Probate
Events ~ Travel Notes ~ Travel
Those pairs could be assigned the same GEDCOM Tag so that they merge into one fact in FH if that is appropriate.
Probate GEDCOM Tag PROB is a Standard GEDCOM Event.
"An event of judicial determination of the validity of a will. May indicate several related court activities over several dates."

Hi Mike

Is this Probate problem being caused by us giving the same Gedcom tag - PROB - to both an Events field and a Notes field prior to exporting from Generations ?

Thanks.

Paul

[tatewise]

Not exactly. It is the use of the valid standard GEDCOM Event PROB tag that does not allow anything on the same line.
Leave it with me for the moment and let me decide on the best solution.

[tatewise]

I have decided to fix the Probate (INDI.PROB) Note problem as it is imported currently using a plugin.

The other two plugin fixes I provided earlier have been combined with this third fix into one new plugin.
It now also produces a Result Set of all the conversions it performs so you can review them.

The new Generations Fact Fixes plugin Version 0.1 Date 01 Apr 2022 is attached below.

Please run it on a Copy of the imported Project until you are happy with what it does.
Remember, you can use Edit > Undo Plugin Updates to reverse its conversions but only before closing FH.

[Paul Wigan]

I have decided to fix the Probate (INDI.PROB) Note problem as it is imported currently using a plugin.

The other two plugin fixes I provided earlier have been combined with this third fix into one new plugin.
It now also produces a Result Set of all the conversions it performs so you can review them.

The new Generations Fact Fixes plugin Version 0.1 Date 01 Apr 2022 is attached below.

Please run it on a Copy of the imported Project until you are happy with what it does.
Remember, you can use Edit > Undo Plugin Updates to reverse its conversions but only before closing FH.

Hello Mike

I have just downloaded and tested the new plugin, albeit on a very small dataset with three Probate problems, and it has worked a treat !

I am intending to do a lot of importing this weekend, with some far larger datasets. I will test it further and let you know how I get on.

Many thanks.

Paul