* Automated internet Marriages lookup

[jbtapscott]

Mike

One issue I did have (on my first run) was a crash!. I chose an Individual born in the 1700's and selected the "UK Birth / Baptism Records" and "All Descendants..." options (Ancestry disabled / FMP enabled). The "Searching Individuals Progress" bar ran through to the end and then started again but stopped at 43% (Record ID 994) with the following message displayed:

[string "C:\ProgramData\Calico Pie\Family Historian\..."] datepoint:SetValue - Invalid number of arguments
stack traceback:
[C]: in function 'SetValue'
[string "C:\ProgramData\Calico Pie\Family Historian\..."] in function 'AdjustBirthDate'
[string "C:\ProgramData\Calico Pie\Family Historian\..."] in function 'LookupFactData'
[string "C:\ProgramData\Calico Pie\Family Historian\..."]:4093: in function 'TblIndividualDetails'
[string "C:\ProgramData\Calico Pie\Family Historian\..."]:4349: in function 'RecordsMissing'
[string "C:\ProgramData\Calico Pie\Family Historian\..."]:4456: in function 'RunLookup'
[string "C:\ProgramData\Calico Pie\Family Historian\..."] in function <[string "C:\ProgramData\Calico Pie\Family Historian\..."]:3165>
(tail call): ?
[C]: in function 'MainLoop'
[string "C:\ProgramData\Calico Pie\Family Historian\..."] in function 'ShowDialogue'
[string "C:\ProgramData\Calico Pie\Family Historian\..."] in function 'GUI_MainDialogue'
[string "C:\ProgramData\Calico Pie\Family Historian\..."]:4511: in main chunk

For info, (Individual) Record ID 994 has a Birth Fact with a full date but a Place only containing a single value (the Country) in the last column). The record has no Baptism Fact.

Afterwards, I selected a later (datewise) descendant and it is returning a valid, much smaller resultset along the lines of what I would expect. I'll have a look in more details at these results over the next day or so and get back with anything else that I find.

[tatewise]

Brian, good spot. Yes, the Plugin can easily check both Event Date and Citation Entry Date in next version.
I have assumed all along that only the 1st Citation ever needs checking. Does that seem OK?

Brent, I know the errors occurring when dealing with an After date, but I cannot reproduce the error.
It is in the special corrective code to add sanity to the FH EstimatedBirthDate() miscalculations.

The first progress bar is actually Finding Relations who are descendants of your "Individual born in the 1700's".
The second progress bar is Searching Individuals found by the above search for BMD details.

It probably is not Record ID 994 that is causing the error, but the next Individual record.
Please identify the next higher Record Id who is a descendant of your "Individual born in the 1700's".
Let me know the details of their first Fact with a Date which must be an After date.

[jbtapscott]

Mike

Record ID 995 is the sister of ID 994. The first (and only) Fact for this Individual is a Birth Fact - Date = "After 1939" and Place = ", , , , Australia" are the only two pieces of data on the Fact. Hope this helps.

[tatewise]

Brent, there is nothing unusual about that Event, so it should be OK.

I have tested a bit further and there is no problem with FH V5.0.
But on FH V6.2 it always gives that error when the SetValue() function is given all 6 valid parameters.
Removing the last one or two, that are not too important, cures the fault, so I will report the bug to Calico Pie.

So attached Plugin Version 0.8 Date 20 Oct 2016 should fix problems.
[Attachment deleted as now superseded by V2.0 in Plugin Store.]

[brianlummis]

Mike, I have just got back from a day out so catching up with progress.

Having tried the latest version 0.8, I am assuming that you have not as yet implemented the Entry Date filter as my Result Set still has individuals with GRO sources listed. Just to clarify my method of recording sources for BMD facts, I tend to make a note of all GRO entries unless I have an original or copy certificate. This means that there can be a number of sources which include original Parish Records and/or Transcripts as well as Census returns, Wills, Monumental Inscriptions and Personal Recollection etc. These sources can be in any order. It is only the GRO Index items that have Quarter Dates recorded as Entry Dates, so in my case any Quarter Date that appears as an Entry Date could be filtered out as being one where I already have extracted the GRO Index details.

This may not be true for everyone so a belt and braces approach would to only eliminate those where a Quarter Date is recorded as an Entry Date AND where the Source Type is the same as the Keywords. The only problem is that others may adopt a different approach for recording GRO Index sources so this may not be a universal answer.

Brian

[tatewise]

V0.8 does allow for Quarter Date in either the Event Date or the Citation Entry Date and checks the Source Type but only for the 1st Citation, which probably explains why yours are not detected. I was working on the assumption that the strongest evidence for a Birth/Marriage/Death Event Date as narrow as one Quarter would be the GRO Index and so that would appear 1st. It would only be trumped by a Source that gave an exact Date such as a Certificate or a Parish Record, but those would also inhibit the lookup search too.

However, I can look at looping through Citations to find a Quarter Date Source Type match.

[brianlummis]

If you can loop through the Citations that would be very much appreciated.

The trouble is that we all have a different way of working which doesn't help when you are trying to write something logical like a Plugin. My rough ordering of Sources is that which gives the closest match to a definitive date comes first, so in the case of births that could be a baptism when the date of birth is noted, a Monumental Inscription which has the date of birth and quite frequently the 1939 Census. All of these will have an "exact" date whereas the GRO Index just gives a range of dates when you expect the birth to have taken place. This is of less importance to me but does help to confirm that the "exact" date is probably correct.

One anomaly that I have just thought of is where the date of birth has been obtained from a Death entry in the GRO Index as is the case for deaths registered after mid 1969. If the Birth entry has not been entered from the GRO Index, then it will not appear in the Result Set for Births/Baptisms as the source of the Birth Date is the Death entry in the GRO Index which in my case has the same Source Type (GRO Indexes) and a Quarter Date in the Entry Date. However I can live with that.

Brian

[tatewise]

Brian, the cases you mention, where an exact Date Citation comes highest, is exactly what I was saying trumps a GRO Index.
If say a Birth Event has an exact Date and a Citation, then it is NOT included in the Result Set anyway, because that is unlikely to be bettered by an online search.
So there is no point looping through further Citations to find a Quarter Date GRO Index that would also exclude it from the Result Set.

Your 'anomaly' is not such, because an exact Birth Date with Citation of Death GRO Index is unlikely to be bettered by an online 20th century search, and does NOT appear in Result Set due to the 1st rule "Exact Event Date with a Citation". The Quarter Date Source Type rule for GRO Index is irrelevant. The Birth Event Citation could probably only be bettered by buying a Birth Certificate.

To summarise, there are two rules that exclude BMD Events from the Result Set search:
1) Exact simple Event Date with any Citation.
2) Quarter Date Source Type match for such as GRO Index on 1st Citation only.

Given those rules, do you still think a looping search is worthwhile, bearing in mind that it may slow the whole lookup process, and may only exclude a few extra rogue events where the Citation order is abnormal.

[brianlummis]

I think that I now understand the methodology and given what you say, I think that looping will be more of a hindrance than help. As it stands the Plugin is a very good searching aid and has already found some records that I had previously missed or have only come online in recent months.

Brian

[tatewise]

I am glad that makes things clearer, and it helps me with what needs to go in the Plugin Help & Advice pages.

Earlier you say "my Result Set still has individuals with GRO sources listed" and "These sources can be in any order".

Later you say "My rough ordering of Sources is that which gives the closest match to a definitive date comes first".

So if some GRO Sources are still listed, maybe that indicates where the Source Citation order needs reviewing?
i.e. Perhaps the GRO Source should be first, as that gives the narrowest Date range.
Then the Event would be eliminated from the Result Set due to the 2nd Rule.
Whereas, currently the 1st Rule is false due to an inexact Event Date, so the Event is included.

The only type of scenario I can think of that you may have to live with is where a Baptism Record gives an inexact Birth Date, but more exact than the Birth GRO Index Quarter, and similarly where a Burial Record gives an inexact Death Date, but more exact than the Death GRO Index Quarter, or likewise for other Sources.

[jbtapscott]

Mike

I have downloaded the latest plugin (v0.8) and run my original test against it (using the ancestor from mid 1700's) and no errors are produced. Looking at the Result Set, ID's 994 and 995 are not listed, but thinking about it, they should not be as (if my interpretation is correct), the check should have noted that they were born in Australia and excluded them on that basis.

I have tried a few other options (eg Single person, etc) and have not found anything that has not already been explained (eg GRO Index related Source Citation was not the first for a given Birth fact). My logic (?) when ordering Source Citation's has been to list them in the order of entry - thus, if a child's Birth Fact (or its actual existence) is based on a Census record then the first Source Citation against the Birth Fact relates to the census and if / when I find a GRO Index (or other) source that confirms the birth then that becomes the second Source Citation, etc. Perhaps I will need to rethink this.

I'll carry on trying other combinations and let you know any issues that arise.

[tatewise]

Brent, the check for foreign Place names should only apply if you have ticked Use their Events to decide if each person was at home or abroad on missing BMD Event dates? so if you untick that option then those two records should be included as long as they satisfy the 'missing Event' criteria. Alternatively, run the Plugin lookup for Australia Birth/Baptism Events.

The usual convention for Citations is to put the most significant ones with the highest Assessment above any others.
The order in which you discovered the Facts in the Sources is not important from a family history perspective.
There are several reasons for the above convention:-
In Reports the most significant evidence for each Fact will be listed first in their superscripts.
When producing Diagram Icons, or Records Window Columns, or Property Box Tab Fields, or Queries to review Sources, the Expressions needed get very complex if the best Citation is not first.
e.g. A check for missing BMD Certificates would be extremely difficult if their Citations were not always first.
Whereas, in your case they might often be last, which could be any instance from [1] to [9] or more.

[jbtapscott]

Thanks Mike - should have said that I ran it with the "Use their events..." option ticked - I'll try a few runs with it unticked and report back if I find any problems.

Points taken re Citations, but I suppose the question comes down to use of the word "significant". I have taken the view so far that, say, a Census record showing that a child is the son / daughter of (say) the Head of Household is more significant than a Birth GRO Index record which does not give any indication of the parentage of the child (other than the surnames) and thus could not, on its own, be used to "link" a child with their parent(s).

[tatewise]

Yes, the dilemma of where to put Sources for relationships is an interesting one.
Some other genealogy products allow Source Citations on the relationships, but they do NOT export into Gedcom.
FH V6 added a neat solution by using Witnesses to the Birth Event as explained in how_to:about:version_6.x.y|> Family Historian Version 6.2.2 for New in 6.1.4 (Feb 2016) under Add Source Citations for Parent-Child Relationships as well as Spouse Relationships. The advantage of this technique is the Witnesses (Father & Mother) with the Citations appear in the Property Box of both the Parents and the Child.
Alternatively, those relationship Source Citations could be added to the <whole record> because they apply to the whole person rather than just their Birth Event.
Then with either of the above, that leaves the Birth Event free for Birth Source Citations, although you may still want the Census Source Citation but lower down as the Date & Place details are likely to be less accurate than a GRO Index.

[tatewise]

The attached Lookup Missing BMD Records Plugin Version 0.9 Date 21 Oct 2016 adds a few minor refinements for special cases that have come to light during testing, but mainly it adds an Event Data column to the Result Set to identify the Event that was pivotal in deciding that BMD records are missing. For Marriages this will add a row for each missing Marriage Record such that the number of Result Set rows equals the number of Lookup Web Page rows.

That Event is often the one whose Date, Place, and Citation are deciding factors, but sometimes later Facts play a part.

Note that for Marriages the Event might be the Birth of the 1st Child for the Individual in first column.

Sometimes, no Event Data will be listed, because there are no relevant Events, but there is enough information in your database to produce an estimated Birth or Death date and form a lookup search.

So far the Plugin has treated any full DD/MMM/YY single Date as an exact Date even if qualified by Approximate, Calculated, or Estimated, but should those be treated as inexact just like partial or range Dates?

This may well be the last prototype before publishing in the Plugin Store next week.

[Attachment deleted as now superseded by V2.0 in Plugin Store.]

[jbtapscott]

Mike - have downloaded the latest version and will come back asap if I find any issues.

So far the Plugin has treated any full DD/MMM/YY single Date as an exact Date even if qualified by Approximate, Calculated, or Estimated, but should those be treated as inexact just like partial or range Dates?

Don't know if it helps you decide, but personally, I only use full dates if I know it is correct (e.g. it comes from, say, a BMD Certificate) - I tend to use the month / year combination with "circa" if I have any doubts or it is a calculated / approximate date (e.g. a Census return saying a child is X months old)

[jbtapscott]

Mike - I have found what appears to be an issue with the new Event Data column in that it is showing data from the previous record in the result set. By way of example:

Marriages.JPG (29.03 KiB) Viewed 9070 times

Here, the Event Data against Jane Tapscott ("Married Q1 1917...") is actually the date that Edward Henry Tapscott got married. The Event Data against Edward Henry ("Married 14 ... in Australia") is the date that Belinda Jane Fowles got married.

For info, I was using the "UK Marriages.." option and the "Use their Events.." was ticked.

[jbtapscott]

Mike - I think the Marriages issue may revolve around Family records where there is only one spouse listed. I reran the Plugin and got the following:

Marriages 2.JPG (53.99 KiB) Viewed 9066 times

The above shows the first five records in the Record Set, plus Jane Tapscott at the bottom. Marjorie has four Family records - the first, third and fourth include a named spouse, but the second has no spouse BUT does have a child listed (born on 15 March). The Status on this Family record is blank. The first Family record has a Quarter date, Place and GRO Index Source Citation, while the third and fourth have "circa" a year and no Place.
Selina has a similar setup in that she has two Family records - the first has no spouse BUT does have a child (born 17 October). Status on this record is blank. The second Family record has a "full" date, Place and GRO Index Source Citation.
Jane is the same as Selina with two Family records, the first has no spouse BUT has one child (Born in 1835) - this time the Status is set to "Unmarried Couple". The second Family record has a "full" date, Place and Source Citations (but not to GRO Index records).

Interestingly, I have rerun the Plugin several times now and seem to be getting different Data Events in the resultant Record Set against the records from Jane Tapscott onwards each time I run it!. I'll continue reviewing this during the next few hours and post here anything I find.

[brianlummis]

Mike

Having been away all day yesterday, I have now caught up with progress. I have also been reflecting on what can and can't be achieved by the Plugin and trying to clarify my thoughts.

As far as pre 1837 events are concerned there appears to be no problem in the results, or in my mind. It is the post 1937 events that I am a bit troubled by. I believe that I am correct in stating that if the fact includes a Quarter Date or the Entry Date contains a Quarter Date AND is the first citation then the individual is not included. However FMP or Ancestry could well have a Birth, Baptism, Marriage, Death or Burial record that would give a more accurate date than the Quarter Date but this possibility would not appear in the Result Set. Indeed, going back to the origin of this post, you may well have already entered the details of a Marriage from the GRO Index in FH but the Plugin would not give you the ability to search for the actual marriage record.

From what you have previously said I know you regard the GRO Source as giving the narrowest date range but the same could be said for the date qualifier circa followed by the full date or the month and year which, for example, some people use for a Death with the date being obtained from the Burial. To complicate matters further I tend to use the before date qualifier quite extensively for Births and Deaths from Baptism and Burial sources. The problem is that there is no standardised use of the qualifiers but I am just highlighting what I perceive as a difficulty.

I am not sure if there is an easy answer apart from an extensive range of filters which I guess is not desirable. However I think that the Help and Advice Notes may need to reflect the limitations as at the moment the Result Set does not appear to cover all situations.

Brian

[tatewise]

Brent, thank you for the feedback. The Marriage/Family search is more complex, so I will investigate scenarios based on your descriptions.

Brian, thank you also for your thoughts, but some of your observations are not quite accurate.

You say "if the fact includes a Quarter Date or the Entry Date contains a Quarter Date AND is the first citation then the individual is not included." But that is not complete, because that first Citation must also link to a Source whose Type matches the Plugin Quarter Date Source Type text before the Individual is not included. However, that text is optional, and if left blank the Individual is NOT excluded, so allows you to search for Birth, Baptism, Marriage, Death or Burial records that might be more accurate than the GRO Index.

The Plugin by default currently includes any Individual whose Event Date is inexact.
This includes all Range and Period Dates such as From, To, Before, After, Between.
BTW: These are NOT qualifiers, they are Ranges and Periods.
It includes all Quarter Dates, which is just a special Range Date, if Quarter Date Source Type is blank.
It also includes any simple Date without a Day such as Jan 1900, or 1900, regardless of Qualifier.
In addition it includes those with no Date at all, as long as an estimated date is available.

The Plugin only excludes simple Event Dates that are exact, i.e. have a Day & Month & Year defined.
(and only then if there is a Citation.)

My only doubt is about such simple exact dates with a Qualifier: Approximate(Circa), Calculated, Estimated.
Currently, the Qualifier is ignore, but perhaps it should be treated as an inexact Date.
But remember it only matters if there is a Citation.

[brianlummis]

Thanks, Mike, for clarifying that there is already an option to allow a search of those individuals who have a GRO Source to see if any other records are available. I had not thought through the consequence of leaving out the Quarter Date Source Type when running the Plugin. Maybe it needs a slight tweak in the User Option section of the Help & Advice as at the moment it reads as if the entry of the Source Type is a requirement and not an option.

Brian

[tatewise]

Brian, I've updated the Help & Advice both on the User Options page and the F.A.Q. page under What factors determine that a BMD Record is missing?

What are your thoughts on my doubts about simple exact dates with a Qualifier: Approximate(Circa), Calculated, Estimated and a Citation?
Currently they are excluded, but should they be treated as inexact Dates and included?

[brianlummis]

Mike

I have been musing over this and hoped that someone else would chip in, as like you, I am unsure whether simple exact dates with a Qualifier should be included. I can see the possibilities for Approximate (circa) and possibly Estimated where it would help but I am having difficulty in envisaging when the Calculated would apply. You have added the additional criteria for there being a Citation as well and here I am wondering whether this should be specific Source Types relating to BMD events only or all Sources.

Unfortunately, I am not the best person to ask as from a quick look at my use of dates, and from my own knowledge of my method of working, I cannot find any example of a simple exact date with a qualifier in my 4000+ records. So for me it is immaterial but others might find an unintended consequence.

Sorry that I cannot be more helpful.

Brian

[tatewise]

Brian, I only mentioned the Citation criteria, because if there is no Citation the Event is included anyway regardless of Date format or qualifier.

You seem to be saying the same as Brent, that at least for BMD Events, when there is an exact simple Date you do not apply qualifiers. So it would make no difference to you which way the Plugin operated.

The Plugin coding change is quite simple, so I will probably treat such Qualified Dates as inexact and include their Events in the search Result Set. If it becomes an issue, then an option can be added.

[brianlummis]

Mike

Thanks for the explanation of why the Citation element is required. Once again I had jumped to the wrong conclusion.

For one, I would be happy with the Plugin as it stands at the moment. This may be a case where it is better to have the possibility of a few "wrong" results rather than changing the criteria to something that may miss results or possibly find that the change is not needed at all.

Brian