Geni consistency & plausibility checker

Charlene Newport yes smart copy, the consistancy checker is part of it and brings up a lists of all the problem profiles and you can one click change the names from all caps to normal.

Thanks Jason, just had a look, now it's supersmart copy! Thank you Jeff :)

Randy Stebbing, Thanks for the note on the sibling comparison. I'll rewrite it to only compare siblings from parent sets, instead comparing all siblings.

Thanks Randy Schoenberg :)

Great question, Randy (re: https://www.geni.com/discussions/167766?msg=1150607)

How should step-siblings be dealt with?

I'm thinking that maybe that should be a separate configuration & "test" item.

That is:
-- the current test for 'close births' gets restricted to siblings with the same parental pair (on the 'same relationship', if you will).
-- a new test for step-siblings which only "share" one common parent; that is, I think, a useful distinction, particularly if one of the parents is currently "unknown" ... one can investigate if that child is truly a step-child or simply mis-connected.

And, when one is spending time in the "Utah tree", one might turn it off while looking.

Ha, cross post. Yup, breaking it out by parent sets. But now that I think about it I need to only do so for the male. Even if the mother had separate partners, the sibling rule should still apply.

True!

What about surrogate birth? :)

More seriously, did you also exclude adoptees and foster children? I didn't check.

Private User can you add "fix" for double space in name error please

Private User, yes - it only looks at biological for comparing sibling and parent / child dates. Jason Scott Wills, will do.

I have difficulty with the spaces in name - often can't find them!!! It crossed my mind that if we could propagate a list of profiles we manage etc. where there inconsistencies/plausibilities we could concentrate on cleaning up. Thoughts?

The "double space" thing is frequently caused by trailing spaces - it seems that it detects double spaces after concatenating up the name. Would be a good candidate for a "fixme" button (now that I know such a wonderful thing is possible :-)!

I have several 'nice to be able to do in a single click' items; some of them (e.g. #1 & 2) I'd turn off when working in the "historical tree" (e.g. medieval Europe and older), but they'd be really nice in many situations:

1) male: Birth-surname empty, last-name not empty => option: copy last-name to birth-surname.
2) female: Birth-surname same as last-name of one of the spouses ... or empty, her last-name not the same as one of the spouse => option: swap last-name & birth-surname

3) "Sr " or "Sr. " (space or end-of-string delimiter) at beginning of suffix => fix: replace with "I " (space or end-of-string).
4) similar to #3 for "Jr. " => "II "

The interesting issue with all of these is for profiles which are not default (English) fields ... I haven't looked into any such areas yet.

one click removes Mr. Mrs. etc would be nice too

I argue against replacing Sr / Jr with l, ll. I put in Sr / Jr (etc) record based. Haven't actually seen Roman numerals except for Royalty until lll, IV .... (I refer to England & USA).

But needs to move from name field to suffix, so that would be good

I've seen cases where John Johnson (sr) has a father named John Johnson (no suffix) and a son named John Johnson (jr). Agree that these values need to be source-based ("he used the Jr suffix"), not added by us because the same name is used in multiple generations.

Ha! Erica. I think you were the one that pointed out (with a reference to a 'style' guide) that for NON-Living people the preference was to use Roman numerals, since the Sr. / Jr. designation often changes as a family ages.

That one's not a biggie for me, and (if it were added as a 'one-click fix') I'd even suggest it be off by default. But these 'one-click' fixes are faster than opening a profile for edit.

I agree that moving a trailing " Sr."/" Jr."/<Roman-numeral> from the First-name field to suffix would be nice (as a separate rule).

Hmmm ... I could even see a whole "class" of nice-to-be-able-to-fix rules which might be off by default, but are all sub-grouped with a "enable/disable sub-group" switch (sort of like ticking individual location fields vs. the top-level location tick-box in SmartCopy).

With them off by default, they won't "clutter up", but if one wants to do some "clean-up" in a section of the tree, then click-to-open-SC, click-config, click-to-enable ... and a refresh to see what cleanup can be done in the area.

I love the fix case button.

Yup, I had found that "genealogy" style guide. Have since found that I can't support it on a record basis. :)

And what Harald said. And Justin has said: the jr becomes sr; the sr is the first in the town of that name, not actually related; and so on. I use location suffixes / display names instead (record supported). England does it better with "the elder" and "the younger."

But get them out of name fields!

Consistency checker is flagging this:

Birth Surname of (wife) is the same as the last name of her husband

Well, yes, especially if they are paternal cousins. Is there any way to make this go away for that profile? I know the intent is to check it, but simply clicking the "x" in the upper right corner doesn't make it go away and it reappears consistently while I'm trying to build her Family Group.

Private User, there is an option in configuration to turn off that particular check as the CC runs (you could do so temporarily if you'd like while you work on her family). I don't currently have a method for persistence on click the X. It's on the wish list - just not sure how to implement it yet.

Currently working on Randy Stebbing's step-sibling bug observation, then I'll work on adding new features such as the quick fixes.

Correction half-sibling bug.

Is it possible for any one of you to rewrite the Geni's estimation of births, because it is totally flawed, in what world is the mother, (human being), 1 year old when she had her first child? Look at this example, Geni estimates her birth to be in the range of 1827-1887, despite the fact that her first child was born 1888.

It looks and feels like a joke, at least, add 12 years by default to those poor people or would that hurt some unknown minority? 1827-1887 is so off track that if she had been born 1827, she would have been 61 when she gave birth, and anything near the end of the last decade is ridiculous, so one solution would be to actually implement something that actually reads from known births for women where the date of births has been left blank, and deduct from that, so that the range never exceeding 52 years, and never goes under 12, but I guess that's too much work to do.

Alfhild Arwidsson

Well, she was born 1863-09-14, and married 1887-10-13, just saying. Who wrote that piece of estimation code garbage anyway and what calculation behind it does indeed affect it?

Randy Stebbing, the half-sibling (children) issue should be resolved in the latest version 4.1.3.4

Ulf, I think it's just doing a +/-30 yrs on the spouse's birth (at least in this case). I expect the estimation when there is no date is designed to be very very broad.

Version 4.1.4 is out and adds several quick-fix links for name warnings. Fixed self-comparison range that included a month, such as death after burial warning when the burial just had month / year.

v 4.1.4: FindAGrave parsing issue:

For this Geni profile: 6000000058886594405 ... this page parses the birth year & location correctly, but not the analogous death year & location.

https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&amp;GRid=5361593

Thanks Jeff for the update that fixed the issue I reported on half siblings.

Some cultures do not bury the dead just after dying. It can take months.

I would recommend to make burial/death check selectable or at least include a parameter

For example: Tana Toraja

http://www.ancient-origins.net/ancient-places-asia/toraja-people-an...

Valentine, the checker is not looking for a range after death. It's just looking to make sure the burial date is after death - that they're not buried alive. The problem was that when a month and year were present, the date libraries assume the day is 1. So if you said they died on 8 Aug, 1974 and had the burial as Aug 1974, the date function is going to assume 1 Aug 1974, which places it before 8 Aug, thus throwing a flag. In v4.1.4 if there is no day and the month and year match, it will no longer flag as a warning, considering Aug a range.