Jump to content


Photo

Treeshare may pick wrong Ancestry birth fact


  • Please log in to reply
8 replies to this topic

#1 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 29 June 2017 - 05:11 PM

Something to add to the Magic Guide - if you have a person in an Ancestry.com tree with multiple birth facts, one of them marked 'Preferred', the download to RM tree may pick the wrong birth fact, and set their birth date wrong.  I have now found this to happen on 2 separate persons, and I have many more to examine.  In both cases, the preferred fact had the most sources associated with it.  (I don't know if this may occur with other facts, if multiples in a profile.)  Once you discover the mistake, it's fixable, just mark the correct fact as 'Primary'.

 

(I should have spotted this and reported it in the beta period, but didn't see it then.  I don't know if I missed it, or it's a new bug.  I certainly could have missed it, but would be surprised if everyone else did too.)



#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8336 posts

Posted 30 June 2017 - 08:38 AM

It's in there!

 

Magic Guide page 3, first bullet point under "Ancestry Tree Not Supported when Downloaded or Updated by TreeShare"

 

'Ancestry does not send "Primary" settings for events'


Renee
RootsMagic

#3 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 30 June 2017 - 09:38 AM

Thank you, I missed that, missed the significance of that statement.  I searched 'birth' and 'facts', but didn't generalize it enough to search 'preferred' or 'primary'.

 

But I think most will not realize how significant that is.  There are good reasons for multiple birth facts, multiple death facts, etc, when they are in dispute, when there's conflicting evidence.  You may have sufficient evidence and sources to say one date is 90% confident, but you can't rule out the other yet.  And the significance is that this can effectively change the birth date on a person, something rather vital!

 

May I recommend additional verbiage there to clarify the significance, and why users should check their results, whenever there are multiple facts, in dispute.  And I would like to recommend requesting Ancestry.com to provide the "Primary" settings (Ancestry.com "Preferred" settings).  Both RootsMagic and Ancestry.com support the same feature, might as well keep it in sync.



#4 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3445 posts

Posted 30 June 2017 - 09:56 AM

There are good reasons for multiple birth facts, multiple death facts, etc, when they are in dispute, when there's conflicting evidence.  You may have sufficient evidence and sources to say one date is 90% confident, but you can't rule out the other yet.  And the significance is that this can effectively change the birth date on a person, something rather vital!

 

Philosophically, I agree 100%. But I do my data entry a little differently.

 

Multiple facts of the same type for the same person can create all sort of problems within RM itself and for data interchange with other systems. Therefore, I try to have only one fact of each type whenever possible. For things like marriages, it's not possible. But for births and deaths as an example, it's possible to have only one fact which represents the primary or most probable data, and to include conflicting evidence and a discussion thereof in the note for the fact. This approach may not feel very satisfying philosophically, but it solves all manner of practical problems.

 

Jerry



#5 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8336 posts

Posted 30 June 2017 - 10:59 AM

I will pass the Magic Guide suggestion along.


Renee
RootsMagic

#6 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 30 June 2017 - 02:19 PM

I will pass the Magic Guide suggestion along.

 

I was hoping you would also say that RM was jumping on it, would propose something to Ancestry.com, and in another week there would be a new version!  Then I could re-download my tree, and not have to check every single person.  Oh well ...   :)



#7 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 30 June 2017 - 04:25 PM

 

Philosophically, I agree 100%. But I do my data entry a little differently.

 

Multiple facts of the same type for the same person can create all sort of problems within RM itself and for data interchange with other systems. Therefore, I try to have only one fact of each type whenever possible. For things like marriages, it's not possible. But for births and deaths as an example, it's possible to have only one fact which represents the primary or most probable data, and to include conflicting evidence and a discussion thereof in the note for the fact. This approach may not feel very satisfying philosophically, but it solves all manner of practical problems.

 

Jerry

 

I was afraid of that.  I had thought about that possibility, then thought about all the extra work I would have to do!  But if other systems also have trouble with it, then I may have to.

 

But it really goes against the grain of a pure data centric approach, as opposed to free form notes, with unlinkable data embedded.  I'm fairly new at this (learning from all of you!), started small with an Ancestry tree and a RootsMagic tree, hoping to merge them into one sync'd tree.  But the world of genealogy is a world of sidetracks, and I'm easily sidetracked.  I discovered FamilySearch, WikiTree, DNA testing, FindAGrave, geni.com, etc etc, and each one is a time-consuming world by itself.  I've been working lately in all of them, and seeing the differences in methodology and data handling.  Differences in methodology are expected, it's product differentiation and competition, a nuisance but acceptable.  But differences in data handling is a real problem, and it shouldn't be.

 

I've been thinking about the basics, and trying to determine what the data model should be, because if you determine the correct model and requirements, then everyone should be able to agree on the basics consistent with that model, and standardization becomes fairly straightforward.  A tree is a collection of 1 or more persons.  A person is a collection of 1 or more facts.  A fact is associated with zero or more sources (should never be zero, there's always a source no matter how bad).  A source is a collection of 1 or more facts.  A relationship is just a fact, special only in that it is associated with 2 persons, not just 1.  A fact has modifiers and attributes, like dates, places, and details (including stories and media).  Facts and their modifiers also have attributes like levels of precision (in dates and places, time of day vs only the century, the actual building vs only the continent).  They also have levels of certainty and confidence.  But it all comes down to persons, facts, and sources - all linked data points.  The rest is just input and output controls, templates, display and report formats, and security and privacy controls.

 

If I try to consolidate all into one fact, I point conflicting facts toward one fact, which seems wrong, breaks the model.  If I move the conflicts and their discussion into a note, I can't readily break it out, access the differing facts as data points.  If I have a birth fact associated with 2 census records, and another birth fact associated with 3 census records, then consolidating them means 2 census records now point to a birth fact in conflict with what they say.  That's wrong to me.  Even if it's fully discussed in a note, it's just not right from a data centric view.  I do realize that from the human reader point of view, it looks completely fine.  But the human reader often doesn't realize what the limitations are, doesn't see the report forms possible if each data fact was separately addressable.

 

I've really come to like WikiTree.  I like the whole idea of one permanent tree community edited, I like the very nice and helpful community, I like the strong emphasis on sourcing everything, I like the exceptional way they deal with DNA tests (automatically propagating results, test kits, and haplogroups to all other applicable profiles), and I like the free-ness!  (Except for the free-ness, geni.com is much the same.)  But WikiTree has a huge flaw, in that once you've added the vitals, all of the rest goes in one often very nicely formatted but completely free form biography!  There are often lots of stories, pictures, sources, and footnotes, but it's all one big single piece of data, essentially unbreakable, great to link to, and use as a source of info, but the data can only be printed out one way, the author's way.  That's the extreme form of free form data handling, the road that free form notes start down when they combine multiple facts into one note.   (sorry for so many words)



#8 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 206 posts

Posted 30 June 2017 - 08:47 PM

Since I do a lot of research for other people as well as myself I very often want to show my work before I present a conclusion. My database therefore normally has multiple instances of the same fact including birth and death. This happens because I could have started with a grave marker which only had a year. Later I could find a document with a full date that has a different year, this becomes a second entry. When I present conclusions I may or may not have definitive evidence to provide either to the client or to my family at the reunion. I find it a important that the primary or preferred fact solution be present first and the rest as lesser alternatives.

Normally the first fact transmitted should be concidered primary/preferred and the remainder secondary (or tossed if the system can't handle duplicates). This is what GEDCOM tells us to do (it does not support/need a primary tag). I've noted that some programs that can't support duplicates do the the reverse, meaning the last fact always is save!

#9 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 02 July 2017 - 07:56 PM

Normally the first fact transmitted should be concidered primary/preferred and the remainder secondary (or tossed if the system can't handle duplicates). This is what GEDCOM tells us to do (it does not support/need a primary tag). I've noted that some programs that can't support duplicates do the the reverse, meaning the last fact always is save!

 

That's very interesting.  So Ancestry.com and RootsMagic don't have to extend their API or send anything new, they just need to alter the sending behavior to be conformant to the GEDCOM behavior.  If Ancestry.com were to send the 'Preferred' one first, then the rest, and RootsMagic were to mark the first one as 'Primary', then accept the rest, the problem is completely solved.  Same behavior in the opposite direction - RM sends the 'Primary' one first, and ANC marks it as 'Preferred'.  Sounds like only a small development change on both sides.

 

After thinking about it, it seemed logical that a good programmer at ANC *would* send the 'Preferred' one first, consistent with GEDCOM export, so I tried analyzing my cases of multiple facts, to see if I could figure out what each end is sending, and doing with it on their end.  I haven't been able to find a consistent pattern however, except that RM sorts the multiples into time order.  That does make sense if they are trying to put all facts in timeline order.  Then they often (but not always) pick the first one, meaning that for a conflicting date they often pick the earliest.  I'm hopeful the RM devs will consider making the suggested change.

 

As to other software or site that only allows one fact per 'vital', there's a time to adapt our behavior, as Jerry has done in this case, and there's a time to get vendors to adapt to what we need, in a standard way.  RM does support multiple facts per vital, just needs a little tweaking to fully support it in interchanges.