* Automated internet Marriages lookup

[jimlad68]

Mike, looked at your revised version: As before this will save many keystrokes. I think there would be no end to the possible 'criteria' permutations, so for me this would be fine. If you want suggestions for refinement, at this point I could only suggest more PLACe options. i.e. select any of the 10 PLACe comma separated values. (I think this would also be relevant to jbtapscott's comments)

[brianlummis]

I am getting some strange output as well, Mike.

I have run the Plugin on a small set of data, being my own ancestors. In one case the Plugin suggests an FMP search for an Birth/Baptism event in 1801 - the persons life dates are recorded as bef1776-bef1827 so I would have expected the search to be for 1775 +/- 2 years. The other case that I have looked at is where the suggestion is for a Birth/Baptism search in 1811 - this person already has a Baptism recorded in 1812 and being prior to 1837, there will be no BMD entry so I would not have expected it to be listed.

I have not looked for any other "inconsistencies" just in case I am misunderstanding the purpose of the Plugin.

Brian

[tatewise]

Thank you for the feedback, because as with the Lookup Missing Census Facts there are likely to be refinements needed. However, keep in mind that these searches are never an exact science, and often need some adjustments to the search criteria to find what you are looking for.

In my experiments the Ancestry & FMP searches involving Place names are best restricted initially to County/State and Country. If further details are included, such as UK Registration Districts, then they may not match related Baptism/Marriage/Burial Church Records, etc, that often use informal towns & villages rather than the formal Registration Districts. The situation in other countries than the UK may be different again. So I decided to use just the two most significant Place parts, which would normally be the last 2, but sometimes the first 2, and that appears to fit both your Place structures. Anyway, as with all such online searches, you can, and sometimes must, Edit the search criteria to increase or reduce the matching records to manageable numbers. The Plugin only provides a rational starting point that avoids a lot of manual keying and potential typing mistakes.

The question of what constitutes a missing BMD record is somewhat complex, and is not necessarily the same for all countries. So currently, if there is no exact Birth/Baptism Date, or Marriage Date, or Death/Burial Date, or there is no Citation, then a search is composed, which will occur when only a GRO Index is recorded. Even with a GRO Index in your data there may be more specific records available online, and that GRO Index scenario only applies in the UK from 1837.

However, let's say you wanted the Plugin to exclude Events with a GRO Index Citation. What Plugin option would allow such cases to be identified? Yes, the Date would need to be a Quarter Date, but that alone is not rigorous enough. How would a GRO Index Citation be identified, since there is no universally agreed method? You might have to tell the Plugin the Source Record Type that you use, and that might be different for each type of GRO Index (Birth, Marriage, Death).

Brian, if there is an explicit Baptism Event Date and there is a Citation then no search should be composed, but I have realised the Plugin is only looking for a Birth Event Citation, so that needs revising.

Any suggestions are welcomed.

[jbtapscott]

Thanks for the response Mike - points understood.

For myself (and I know I am only "one"!), I like your idea of utilising the option of selecting Source Record Type (your penultimate paragraph) as I use different Source Type codes for, say, Certificates and GRO Index but as you say, there is no universally agreed method!. For events prior to 1837, I use a "xxxx Parish Record Transcript" style of Source Type code.

[tatewise]

Brian, try the attached Lookup Missing BMD Records Plugin Version 0.5 Date 06 Oct 2016.

When there is an exact Event Date, this should check each candidate Event in turn to check for a Citation.
e.g.
If there is an exact Birth/Baptism Date then first the Birth Event is checked, then the Baptism Event, and finally the Christening Event. Once an Event is found, then it is checked for a Citation. If a Citation is found, then no search is composed.

The same strategy is employed for Death, Burial, and Cremation events.

For Marriage only the Marriage Event is checked.

Brent, do your three Source Types for GRO Index all have a shared keyword or two?
e.g. Birth GRO Index, Marriage GRO Index, Death GRO Index.

[Attachment deleted as now superseded by later versions.]

[brianlummis]

Mike, I have tried the version 0.5 but it still brings up the same results. I am about to go out so cannot look too closely but I was just typing the following response when the new Plugin came through! Maybe it will throw some light on the subject from my perspective.

"Thanks for that, Mike and as you ask for suggestions, here goes!

I was at first slightly confused as the output referred to Birth/Baptism whereas the purpose I believe is to look for Births where BMD details have not been recorded. Therefore the search for baptisms is not really required, although this might be the result of the query when using FMP as births and baptisms form part of the same search - I do not use Ancestry so cannot comment on any results from that source.

The Event date is more critical as for BMD entries we can safely ignore expected birth dates prior to 1837 although it may be prudent to use a 5 or 10 year leeway for any dates that have been incorrectly estimated.

I have also been toying with the idea that there should perhaps be a selection criteria for Births or Deaths or Marriages(or all three) bearing in mind that the OP of this thread was looking for Marriage BMD entries - and since then Births and Deaths have been added. This would allow the user to search for one Event only and may have the added benefit of being able to identify more quickly any errors in the search criteria as it would apply to just one Event."

Brian

[jbtapscott]

Mike - all my Source Type codes for BMD's include a reference to the "type" of data the source record relates to - eg Birth Parish Record Transcript, Birth Certificate, Birth GRO Index, etc

[tatewise]

Brent, I will have a look at filtering events with quarter dates and chosen keyword in Cited Source Type.

Brian, the Plugin tries to help find Birth/Baptism/Christening records, or Marriage records, or Death/Burial/Cremation records depending on which Choose the BMD records to review option is chosen.
Essentially the same search criteria are used throughout, regardless of Country, and regardless of Date.
So in UK it may find:

• any Parish Baptism records, or post-1837 Birth GRO Index records
• any Parish Marriage records, or post-1837 Marriage GRO Index records
• any Parish Burial records, or post-1837 Death GRO Index records

Both Ancestry and FMP lump Birth & Baptism records together, and similarly for Death & Burial records, so one search finds all. In other countries it will find whatever is online, which may be full Certificates in some cases.

[Valkrider]

Mike,

Nice plugin.

Just FYI works fine with Virtual Box, Wine and Crossover just as would be expected.

[brianlummis]

Mike - in my haste to reply I did not notice that you had already given the option of Births or Deaths or Marriage for the UK (as well as other other countries) My apologies I should have known that you would have thought of that before me! Thanks for the explanation.

I am still slightly bewildered by the result from the UK Birth/Baptism query that is suggesting that a birth record should be searched for in 1801. The other details shown for that person are:

Individuals Name -- LUMMIS, Sarah [46]
Life Dates -- bef1776-bef1827
Spouse family at Event -- ...of John LUMMIS and Sarah POLLARD
Family Date -- 28 Mar 1797
Father's Name -- POLLARD, James [3232]
Mother's Name -- WILLIAMS, Christian [3233]

Strangely it is searching in her married name (it is recorded as an alternate name) and is 25 years after her expected date of birth. Sarah LUMMIS nee POLLARD does have an event recorded for Baptism, Marriage and Death, and the only other facts recorded are Born with estimated date and Burial.

Brian

[tatewise]

Brian, I agree that looks strange.
It's using Sarah's married name because search date 1801 is after her Marriage (Family Date) 1797.
But why is it using 1801?
To answer that, could you supply her Fact Dates and Citations?
Perhaps a screenshot of her Facts tab, plus which Facts have Citations (the Source details are not needed).

[brianlummis]

Mike - Here is the screenshot

Sarah Pollard Facts.JPG (32.58 KiB) Viewed 9046 times

The first two items, Born and Baptised, do not have a citation as the Source is a Transcription where I am using Method 2 with a view to replacing it with a copy of the original Parish Register when it becomes available.

Brian

[tatewise]

Thank you that gives quite an insight into what is going on, and how complex the Plugin might have to become.
Currently, it uses the EstimatedBirthDate() function with EARLIEST and LATEST parameters.
In simple cases, where there is only one Birth or Baptism event with a simple Date then the EARLIEST and LATEST dates are both that simple Date.
It gets more complicated if there is no Birth Date and any event has a Date and Age where they get used to estimate Birth Date, and any Baptism Date is ignored!
In your case with a Death Date of bef 1827 and Age of 52 the FH algorithm goes very wrong and gives EARLIEST date of 1827 and LATEST date of 1776, so the Plugin uses mid-point of 1801.
If you remove the bef and just use 1827 then rationality returns.

Clearly there are some bugs in the FH algorithm that I will report, including:
1) Any LATEST date derived from an Event Date & Age must be no greater than a Baptism/Christening Date.
2) Before & After dates must be applied correctly.

Even with those bugs fixed, the Plugin needs to add some sanity checks to avoid composing searches for Baptism or Burial records that are already cited.

[johnmorrisoniom]

Mike,
I have have found that age estimation does not work at all if the DOB is recorded as bef YYYY.
I used to use bef "Baptism date" as birth date if no other evidence, but when building queries this meant that individuals were included who common sense shouldn't be.
EG a query to find individuals born where place contain "Anytown" in 1855, will correctly include those with an actual birth year of 1855, but also include any whose birth is recorded as bef "Any year after and including 1855"

[tatewise]

John, exactly what Expression did you use to filter "born in 1855"?
Did it involve the EstimatedBirthDate() function?
If so, it might add more examples of the estimation function misbehaving.

[johnmorrisoniom]

Hi Mike,
I use two rows, so that can have a date range if needed.
I have attached screenshots showing row filters and result set of both dates set the same

The second row is to exclude individuals who already have a baptism image attached to a baptism source.

Baptism Query Rows.JPG (81.53 KiB) Viewed 9006 times

Baptism Query Result set.JPG (121.56 KiB) Viewed 9006 times

[tatewise]

But John, that is nothing to do with the EstimatedBirthDate(...) function being discussed earlier, because your filters are only testing the actual Birth Event Date recorded in your data, and is doing exactly what you requested. In other words, there is no FH estimation involved at all.

If you use EstimatedBirthDate(...) instead of %INDI.BIRT.DATE% then you should get better results.
Where an exact Birth Date exists, the results should be the same as using %INDI.BIRT.DATE%.
But where the Birth Date is inexact, and other Facts exist, especially with an Age defined, then the EstimatedBirthDate(...) should not extend back indefinitely.
e.g. If there is a Death Event Date, even without an Age, then the earliest EstimatedBirthDate(...) should be Tools > Preferences > Estimates > Maximum Life span before the Death Event Date. If there is an Age then that is used for the EstimatedBirthDate(...).

But we seem to have discovered some serious flaws in the EstimatedBirthDate(...) algorithm.

[johnmorrisoniom]

Hi Mike,
I appreciate your point, I was just making the comment that the use of bef "baptism Date" for birth date can yield odd and unexpected results, and and also stops the "ageat" function producing results.

[tatewise]

=AgeAt(...) only works for single Dates, and NOT for Date Ranges/Periods.
=EstimatedAgeAt(...) works much better, along similar lines to =EstimatedBirthDate(...), especially if you use =EstimatedBirthDate(...) or =EstimatedDeathDate(...) to specify the Date instead of %INDI.BIRT.DATE% or %INDI.DEAT.DATE%, because they take account of many more Factors. See their Help pages for details.

The results you describe may be odd and unexpected from a human perspective, but FH is just a calculator when it comes to Query filters, and does not take lifespan or other factors into account, unless you tell it to.

[tatewise]

I have reported the =EstimatedBirthDate(...) function miscalculations to Calico Pie but with no significant reply.

The attached Lookup Missing BMD Records Plugin Version 0.6 Date 18 Oct 2016 adds some Date of Birth sanity checks that should cope with Brian's scenarios, so please give it a try.

Filtering events with Quarter Dates and a chosen keyword in Cited Source Type as requested by Brent is still to be considered.

[Attachment deleted as now superseded by later versions.]

[brianlummis]

Many thanks Mike - it looks as though sanity has returned.

The Result Set is now much shorter and from the sample I have taken I have not found any "rogue" entries. The Plugin certainly make searching for missing (or in some cases overlooked) records that much simpler and will make sure that I get full value from my FMP Subscription!

If I come across any anomalies as I am working through I will let you know.

Brian

[tatewise]

That looks good Brian.

The attached Lookup Missing BMD Records Plugin Version 0.7 Date 19 Oct 2016 adds the filter requested by Brent.

If a key event has a Quarter Date and chosen keywords in Cited Source Type then the lookup is inhibited.
This caters for post-1837 GRO Index BMD entries for which further records are unlikely to be online.
However, if the Source Type keywords are blank, then the lookup searches will still be composed.

[Attachment deleted as now superseded by later versions.]

[brianlummis]

Thanks for the updated Plugin, Mike.

I do use Quarter Dates so thought I would try the new option but I think that I must be doing something wrong. I use Method 2 for recording BMD entries from the GRO Index which should make life simple. The source is named GRO Index and the Source Type is GRO Indexes. I have used both of these as keywords but the Result Set (for Births/Baptisms) includes those individuals where I have already recorded the source as GRO Index for the Birth fact.

In fact my Result Set is still the same size as before the update. Have I misunderstood the use of the Keyword box?

Brian

[tatewise]

Providing you are setting Quarter Date Source Type keywords = GRO Indexes it should eliminate any Individuals whose Birth Event has a Quarter Date and Citation of a Source with Type field containing exactly the text GRO Indexes.
Do NOT enter any other keywords for say the Source Title.

Maybe a better description than keywords could be used, such as text.

I am trying to cater for the case where the Source Types used might be Birth GRO Index and Marriage GRO Index and Death GRO Index so the keywords/text would be GRO Index to match all three Types.

With a bit more development the Plugin could support a different Quarter Date Source Type for each of the three BMD Record types (Birth/Baptism, Marriage, Death/Burial), or even every Country as well. Then the Source Type would have to equal the entered value in full. But I thought one common value unique to all BMD Records would be easier for the user to enter just once. The value would be irrelevant for countries other than UK, because no citations of a Source with that Type would be used, and Quarter Dates would be unlikely anyway.

[brianlummis]

Mike, I think I have discovered why I am getting a different result than expected. Am I right in thinking that the plugin is looking for Quarter Dates in the date field of the Birth fact and is this overriding the Keyword criteria? Having gone through my Result Set I have no Quarter Dates for the birth but I still have some entries listed where I have already recorded the GRO Index as a source.

I have a number of instances where I have a more accurate date for the birth - many from parish baptism records - where I also note the GRO Index as a Source. Therefore my Quarter Dates in those instances are recorded as the Entry Date in the citation. Is it possible to remove these from the Result Set as well?

Brian