Liz, Lizzie, Liza, Betty are a few that come to mind.

9ZMR-8XL
Eliz. Berrer, "New Jersey Births and Christenings, 1660-1980" has a first name of Eliz, which is different from Elizabeth.

Thanks.

"Mc" names have often been indexed with a space between the Mc and the rest of the name. And, Irish birth registrations have been indexed multiple times. As a result, Mary has multiple "consistent with sources" errors when the algorithm does not recognize that Mc Garrity is the same as McGarrity.

Mary McGaritty, "Ireland Births and Baptisms, 1620-1881" has a last name of garitty, which is different from mcgarrity.

I recognize that there is a variant spelling here, with 1 r and 2 t, but I imagine that would fall within normal parameters for variants if not for the space in Mc Garrity.

Oh - and the record, which was handwritten in 1864, does not have a space. #279.

Thanks.

Now my actual comment. The flag "The death has no tagged sources." appears on anyone who is marked deceased. I'm having trouble deciding what to think about this.

• Should it show up as much as it is going to? Will it have any value if it is on everyone just marked deceased?
• Should this flag be set only if there is death information, that is, a date or place, with no tagged source?
• Would it be a more valuable if there were two flags? One for "This death date and/or place has no tagged sources" and one for "This deceased person is less than 110 years old and has no tagged sources (so maybe should be changed to living)"?

"Deceased" is not really a conclusion. It is just a marker that the person is not alive. Under "Person Data has Tagged Sources," death and burial should be treated the same as they are under "Person data is Complete."

If there is information but no tags it should be flagged. If there is no information, that is no date and place, the lack of tags should not be flagged.

I do realized this is because the death field is not like other Vitals fields because it, like Name, always has to have something in it, either Living or Deceased, but the routine should not be lead astray by that and an exception should be programmed in.

Background: The England and Wales Birth Registration Index, 1837-2008 collection appears to set up the ability to tag the Name and a Custom Event of Birth Registration. It does not appear to tag the Birth event. (Earlier threads suggest that some index records in this collection did do this years ago.)

Similarly, the more recent index records in England and Wales Death Registration Index 1837-2007 are now setting up a Death Registration Custom Event and not a Death Event.

In both cases, the dates involved are recorded only as years (quarters may be specified but as text).

Impact: When sources are attached to a profile, some users accept the default tagging. For an index in the England and Wales Birth Registration Index, 1837-2008 collection, there is a tag against the Name (sensibly), a tag against the Custom Event Birth Registration, and no tag is generated by this process against the Birth event.

For one of these newer indexes in the England and Wales Death Registration Index 1837-2007 collection, there is a tag against the Custom Event Death Registration, and no tag is generated by this process against the Death event.

If these users then leave the situation like that, the index records that are tagged to the Birth and Death events tend to be (I believe) lower quality secondary index records such as censuses (notorious for variable ages resulting in incorrect birth years), newspapers reports (probably accurate on dates - less so on places), FindAGrave inscriptions (possibly done years after the event), etc.

The higher quality primary index records in the England and Wales Birth Registration Index, 1837-2008 and the England and Wales Death Registration Index 1837-2007 collections are then left tagged to the Custom Events Birth Registration and Death Registration. In biographical terms, these two Custom Events have, I suggest, zero significance. The 2 collections represent the only state-controlled means of sourcing accurate births and deaths.

Why was this done? I can only suspect that some people feared that Birth and Death Registrations were done at a materially different time from the actual Birth and Death events. I cannot speak for other administrations but births in England & Wales need to be registered within 6 weeks of the birth itself. There is no concept of a Delayed Registration in the English & Welsh system and never has been. I am fairly certain that deaths are even tighter in timescale simply because doctors, undertakers, parish priests, coroners, etc, won't move until the registration process is in play.

For births, the difference between registration and birth is therefore limited to a maximum of 6 weeks and since the dates are just a simple year, only births in the last 6 weeks of the calendar year may be registered in a different year from the birth year. Interpreting the Birth Registration as a Birth event therefore only affects births in the last 6 weeks of the year at worst.

Would the PQS group agree with me that using the England and Wales Birth Registration Index, 1837-2008 and the England and Wales Death Registration Index 1837-2007 collections to tag the Custom Events Birth Registration and Death Registration instead of Birth and Death events will result in a risk of lower data quality?

(Yes, I'm sure this issue will apply to other administrations as well…)

But I think with nothing more than this notice, users might post the death month/year again. Duplicating that data isn't really informative and would add clutter (IMO).

The thing about burial dates, finding them isn't straightforward. It's something that most of us have to learn how to find. If it can be found at all.

Maybe the Date Missing notice could be clickable and take users to a page with suggestions about how to find burial dates.

Users could learn things like: Some church and cemetery records have exact dates.

Some US states record a burial date and location on the death cert. disclaimer: much useful data is omitted from indexing; freshmen researchers often don't know it's there.

US obituaries commonly have funeral dates and sometimes burials can be inferred from that.

Clever researchers will have their own ways about how to suss out a burial dates but you get the idea.

First some background information to set the stage.

The Places database for Norway is very incomplete. As I have worked in various municipalities I would say that at best about 50% of the needed places within any municipality are included in the database. Of the places that are included, about 75%, as a rough guess, are entered incorrectly in that the place name does not include the municipality, just the place and county. This results in three types of standards in the database:

• Place, Municipality, County, Country
• Municipality, County, Country
• Place, County, Country

I am going to test out each of these situations for place names and see what the Score Details show.

Place, Municipality, County, Country

https://www.familysearch.org/tree/person/details/K2T1-FBK

All his places names in Vitals had appropriate values in the Places database. So everything is fine here, as expected.

Municipality, County, Country

https://www.familysearch.org/tree/person/details/LZGB-R7X

Here, her birth place of Sjørsand, Fusa, Hordaland, Norway, does not exist yet in the Places database and can only be linked to the less complete Fusa, Hordaland, Norway. The scoring routine is looking only at the linked standard and is ignoring that the actual place name does have four parts.

Place, County, Country

I created a temporary person that I have deleted.

Here, the person was born at Hatlestad, Lærdal, Sogn og Fjordane, Norway. Instead of keeping the full version, I used the version currently in the Places database which is just Hatlestad, Sogn og Fjordane, Norway. The routine cannot tell that what is missing is not the “City/etc” but rather the 3rd level of municipality.

If I put in his full birth place, I get the same notice:

Again the routine cannot tell what is actually missing from the place name and cannot tell that the actual place name really does have four parts.

It will takes years to get the Places database for Norway complete. In the meantime, it would be nice if the Quality Score routine could look at the full place name along with the linked standard.

From the first two examples, it looks like the routine does not yet compare profile place names to the tagged index sources.