MyHeritage to FSTree Duplications

LegacyUser

Robert Wren said: I've been 'relatively" happy with the Sync process between MyH & FSTree; HOWEVER it changed today!

Today, I was offered on MyH a "Person Discovery" which caused (when sync was completed) a duplication of a family of seven on FSTree. I believe that I may have added them TO MyH in a previous sync??

BUT it took me a half hour, or so, to get it all back in order (merging the duplicated children).

The error was 'caught' in the subsequent sync (which my have been occurring at the same as accepting the discovery?):
https://www.myheritage.com/familysear...

The problem occurred with the children of PID Thomas Henry Wren KH6X-M59.

I hope FS can nip this in the bud. (and then correct the ongoing GEDCOM problem)

LegacyUser

Jeff Wiseman said: Agreed. This appears to be the THIRD "biggie" with MyH sync issues.

The GEDCOM issue is bad enough, but with the entries there being handled one at a time (even though it is semi automated), it still doesn't compete with the potential damage from the batch synchronizations that MyH performs!

LegacyUser

Robert Wren said: Jeff, this is the first problem I've encountered with the FS/MyH sync; I've done 16 sync so far without an apparent problem. MyH did give notice of "duplicates" after the sync AND the record did show the "Personal Discovery" in the PID source. (It did lead me to a lot of OTHER 'corrections' sourcing and additions.)

It's possible I may have been a partial cause by syncing WHILE working within MyH (???) - but it IS disconcerting!

LegacyUser

Jeff Wiseman said: Well since there have been at least 2 other significant failures with that software, it still makes me quite nervous.

"Your scientist (software designers) were so preoccupied with whether or not they could, that they didn't stop to think if they should"

- Ian Malcolm -- Jurassic Park

LegacyUser

Robert Wren said: “Senator Soaper Says:To err is human, to really foul things up takes a computer"

LegacyUser

Tom Huber said: I don't trust MyH and so have not tried to use it. Anything that I find on MyH, I treat the same way I treat Ancestry finds that are not in FS -- manual updates via Ancestral Quest, which I use for my base programs, to FS.

LegacyUser

jimmy.zimmerman said: Robert,

Would you be willing to meet with me (virtual) to walk me through this experience? I'm working with the MyHeritage team on some improvements and your case could provide some good insights. Email me directly jimmy@familysearch.org

Thanks!
Jimmy

LegacyUser

Robert Wren said: Just had a nice online chat re this problem with Jimmy. Thank you, Jimmy, for jumping in on this.

He was quite adept at analyzing the problem and will be talking with MyH to implement a FIX.

It appears a person in MyH, basically 'adopted' this family from my FSTree PID's. As it then appeared in THEIR MyH tree, it was offered to ME as a 'Person Discovery' to allow me to 'add' some people to my MyH tree. (which then got back into FSTree, in a subsequent sync) Thankfully that sync also identified the possible duplication in the sync report!

I (obviously) did NOT check it close enough to realize it was the same people that were copied from MY FSTree - hence the duplication when I synced again. But I was fortunate to catch it in time and REORT it here in the Forum, thereby giving it notice and, hopefully, a forthcoming solution

I trust this is as clear as mud!

They will be working on a FIX - My Suggestion was to NOT allow (in MyH) the suggestion of new discoveries to people with a FS account for persons in the MyH tree which originated from FSTree.

In the meantime use your best discretion in these offerings -indeed, use your best discretion in ALL hints/offerings/suggestion from any other trees anywhere. Stick to the SOURCES (Not even indexes of sources) for growing you tree.

And REMEMBER that FS indexes still cover a very small percentage of the SOURCE records within FamilySearch. (<30%?)

Now, it we could get similar action with the GEDCOMS!!!
https://getsatisfaction.com/familysea...
https://getsatisfaction.com/familysea...

LegacyUser

Jeff Wiseman said:

As it then appeared in THEIR MyH tree, it was offered to ME as a 'Person Discovery' to allow me to 'add' some people to my MyH tree

Because of all the initial concerns about these sync capabilities that were being developed in MyH, nearly a year ago it was explained to us that you will only be able to sync "Special" trees with FS (i.e., those that had been specifically seeded from FS). We were ALSO told that those trees in MyH would have significant limitations in that normal auto populating functions found in the rest of MyH (such as loading full person records into a MyH tree) WOULD NOT BE AVAILABLE on trees that are sync-able with FS!

For example, although you can load a GEDCOM file into one of your trees in MyH, you CANNOT load it into a tree that can be sync'd with FS. Supposedly manual, one vital at a time alterations were the only types of changes that would be permitted in the sync-able trees since they are just an explicit extension of the SHARED tree in FS.

Jimmy Zimmerman,

Thank you for pouncing on this.

LegacyUser

Brett said: Robert

Regardless ...

I still maintain that WHATEVER a User/Patron uses, be-it, (especially) a (Raw) 'straight' GEDOM File; or, a "Third Party" Application, to UPLOAD, either, an individual/person; or, even, "Data" to an individual/person, who ALREADY "Exists" in "Family Tree" of "FamilySearch"; THEN, the individual/person that ALREADY "Exists" in "Family Tree" of "FamilySearch" SHOULD be the (ONLY) "Surviving" individual/person in "Family Tree" of "FamilySearch"; and, NOT, the individual/person from a 'straight' GEDOM File; or, a "Third Party" Application.

The individual/person from a 'straight' GEDOM File; or, a "Third Party" Application, SHOULD become the "Deleted" (ie. "Archived") individual/person.

Users/Patrons can still ENACT "Changes"; but, at least the ORIGINAL individual/person that ALREADY "Exists" in "Family Tree" of "FamilySearch" is RETAINED, 'in stu'; and, 'to pot' with an individual/person from a (Raw) 'straight' GEDOM File; or, a "Third Party" Application.

Just my thoughts.

Brett

.

LegacyUser

jimmy.zimmerman said: Let me clarify a few things:

1. The sync'ed trees do have limitations. For example, these FamilySearch sync'ed trees cannot sync with the MyHeritage desktop program (Family Tree Builder). GEDCOMs cannot be merged into these trees.
2. The MyHeritage sync'ed trees have been enhanced to include things like reason statements and contributor information from FamilySearch.
3. The sync'ed trees are currently able to receive hints from records and other trees. Person information (including full person) is able to be added to the sync'ed trees.

We are working with MyHeritage to make sure we're addressing duplication concerns and Robert's case will be very helpful in this endeavor.

Thank you Robert!

LegacyUser

Jeff Wiseman said: Hi Jimmy,

Thanks for clarifying all that for us! I suspect that keeping logical errors out of your third point is going to have people scratching their heads :-)

There seems to be a significant group of people who's interest in this hobby is more focused on tree building and name collecting (as opposed to researching and documenting). I've seen a lot of that in Ancestry.com where a common series of errors is passed around, and around, and around, until many public trees have the same identical set of errors in them.

Of course, when everyone has their own private trees, there is absolutely nothing wrong with this. But in a shared tree, this is deadly and can cause a lot of grief for other workers in the tree. That is why being able to directly load large batches of outside records into the shared tree (either via GEDCOMs or large batch sync'ing) can produce large problems.

The "sync-able" tree that a MyH patron has in their account is NOT their own private tree. It is an actual piece of the shared FS FamilyTree that they have linked over into their MyH account for easy access, and it needs the same limitations as direct access to the FSFT does (if not more so :-)

I'm sure that you are already fully aware of all the above, but many users of the FSFT are fearful of the MyH "batch access" to FS due to grief they have had to endure from other types of batch access induced problems (such as data loaded in from GEDCOM file data and people intentionally creating their own separate trees within the shared tree database).

For these reasons I greatly appreciate the responses that you have provided here over the last little while. I suspect that many others here feel the same :-)

LegacyUser

Robert Wren said: A bit more clarification, if I may: My primary reason for using the FS-MyH sync (link) was because MyH had done a great job with Swedish records. In particular, indexing (continuing) all of the ArkivDigital (Swedish) digitized records- which appears to be virtually "all" of the parish records of Sweden. It also provided a relatively simple way to transfer the the record image (SOURCE) to FSTree.

HOWEVER, now that MyH is sharing those image links with FSTree, it appears that we may be getting source duplicates - on of the FS copy (from MyH) & another from MyH via sync of the trees. (For me having two copies is better than NONE, and I try to avoid this duplication.

I do heartily agree with Jeff's comment above "The "sync-able" tree that a MyH patron has in their account is NOT their own private tree. It is an actual piece of the shared FS FamilyTree that they have linked over into their MyH account for easy access, and it needs the same limitations as direct access to the FSFT does (if not more so :-)"

So far this syncing has been a several year process, which I'm still trying to evaluate its value in RESEARCH (not easily copying & transferring info - like GEDCOM)
MY personal goal is Quality, Accuracy - "Records worthy" (see my logo to the left) and NOT Quantity - numbers of relatives or connecting to famous people!!!

I hope, and trust, that Jimmy, et al will find a solution

LegacyUser

Robert Wren said: Brett,
If I "understand" you (correctly), I believe, think/opine, that I agree/understand your point:

!!!Too much garbage is getting into FSTree!!!

LegacyUser

Jeff Wiseman said: My "head scratching" comment to Jimmy was due to the fact that by having that piece of the FSFT in the same space that they have other "Private" or "public to MyH" type trees, they are mixing Apples and Oranges (i.e., Apple trees and Orange trees :-)

There are some things that can not exist in both without creating significant problems.

LegacyUser

Robert Wren said: So you are opposed to cross-pollination, Jeff?

What pollinated most of the world's crops and doesn't take any of the credit?
A humblebee

LegacyUser

Jeff Wiseman said: :-)

Well, grafting branches from one tree into another requires a lot of care, knowledge, and TIME. Inexperience and carelessness is deadly without a teacher or mentor present. Otherwise, the tree dies.

(Of course, nearly everyone in the FS FamilyTree is already deceased...)

LegacyUser

Robert Wren said: Good Point!
I think this social isolation is getting to me!! I need to get back to research.

LegacyUser

Jeff Wiseman said: Yea, me too. And all this pollen in the air ain't helping :-)

LegacyUser

Brett said: Yep

LegacyUser

Robert Wren said: I've just (re)discovered another little 'problem' with the MyH sync. (indeed many sync processes)

MANY sources (e.g. US Censuses) are found on BOTH sites, and commonly pop up as hints in MyH - even though they are already attached to the FS Tree AND the synched 'clone' in MyH.

If attached those 'duplicate' sources will then be added to the FSTree- created yet another duplicate, but different URL, for the same record.

Therefore the FS-MyH synch can (will) cause a great deal of source duplication on FS PID's.

I usually try to "ignore" them in MyH to avoid the problem, but. . .

Notice Jeff's comment to Jimmy's "3rd point" above.
"3. The sync'ed trees are currently able to receive hints from records and other trees. Person information (including full person) is able to be added to the sync'ed trees."
Jeff: "your third point is going to have people scratching their heads"

Easy transfer between various trees on the web is getting EASIER,. . . BUT it is NOT the best way to actually do RESEARCH - which requires (or should require) information that is SOURCED, which web based trees are NOT, necessarily or usually. IMHO, too many are taking the 'easy way' and simply copying aunt Minnie's work. (Think GEDCOM's for a good BAD example)

Adding the same informational SOURCE from many different places also does NOT add credibility toward the GOAL of "records worthy of all acceptation"!!!!!!

LegacyUser

Jeff Wiseman said:

MANY sources (e.g. US Censuses) are found on BOTH sites, and commonly pop up as hints in MyH - even though they are already attached to the FS Tree AND the synched 'clone' in MyH

For the normal run-of-the-mill MyH tree, that is obviously not a problem, and is in fact desirable to document those tree with. However, in the case of a FS sync'able tree in MyH, an ability unique to those trees should be added. It would sort of be like a specialized "Dismiss" function on the hints. It could be an "Already Attached" specific dismissal. But it would need a great amount of visibility of those sources in MyH in order to do comparisons.

And then there is the question as to whether anyone would care (or understand the issue) enough to do it.

If persistent URLs were used, it might be able to automatically catch some of these (i.e., URLs which had not been updated, of which there seems to be fewer and fewer), but the logic on that processing would be really gnarly.

LegacyUser

jimmy.zimmerman said: Regarding the US Census records, are you saying that the result is multiple sources for the same US Census record (FamilySearch version, MyHeritage version, etc.)?

LegacyUser

Robert Wren said: YES, and there are many other potential examples, (And thanks for the PROMPT response!!! Jeff's "dismiss' solution (below) might help. I just "ignored" a couple which I knew would have been duplicates, when I resynched - but that's not an ideal solution.

LegacyUser

Robert Wren said: Jeff, thanks for not disappointing me with your expected response. " ( I expect to see a Jeff response to my recent post to that subject.)"

LegacyUser

jimmy.zimmerman said: How would you see this handled in the case that the Census collection may actually differ on each web property? For example, there are many record collections that exist on both sites, but were transcribed through different processes, by different people, have different images, and capturing different fields. Should the citation exist on the FamilySearch Family Tree person pointing to both versions? What are your thoughts?

LegacyUser

Robert Wren said: MyH is somewhat unique int hat it currently synchs ALL of the change made within MyH into FSTree. From Ancestry the e.g Census record is only transferred when it is SELECTED to be transferred, otherwise is does not. I'm not sure what other sites have the capability. I have seen BOTH Ancestry & FS censuses on PID's, often the FS version may be FindMyPast's (eg British). I sometimes delete one or the other if not significantly different (eg clarity of image, etc). With 'different' transcripts both might be useful.

Where else can censuses (or?) be transferred in mass quantities?? Personally, I'm just not excited about "mass" transfers. No that you mention it I guess FindA Grave records might also multiply??

I just wish that MORE users would actually VIEW the actually source IMAGE, rather than depend on transcript. I'm continually amaze at how much more info is often found in actual sources - or haw bad some indexes or transcripts are.

I guess I got of a tangent here, hope this helps. (and hasn't timed out.)

LegacyUser

Jeff Wiseman said: Jimmy,

That's an interesting question to think about.

1. In general, I would suggest that every citation should point to only one source.

2. An entry in a digitized index file is a source that internally cites an image or paper that it was indexed from. So even if there have been multiple indexes created from the same or similar image, then they are "different" sources, and therefore justify separate citations. (I think that this is particularly important when the original images that were indexed are not available)

3. The fact that "everyone and their dog" is creating indexes from original paper sources (or images of them) or are all filming the same paper sources does create a huge redundancy problem, but due to digital document ownership issues and simplicity of file handling, I think that for now we are stuck with treating different sources as different sources as far as citing them goes (and the numbers problems that goes with it).

4. If a given source in the FS historical records area has been cited already on a record, then hints of that exact same source should NOT be presented to that record again. That limitation is already in FS. The way the MyH tree works, it is just a remote control view of part of the FS tree that is in the MyH account for convenience. All the same rules should apply. If a FS source has been cited on a record that is now visible in someone's MyH account, MyH should NOT be suggesting hints of that same exact source to that record in the MyH domain.

5. Note that this all has to do with digital processing of sources. Obviously, someone could create a custom source citation anywhere which effectively duplicates other existing citations. But for other automated source citations, hinting should be done the same on the MyH FS sync'able tree as it is in the actual FSFT.

LegacyUser

jimmy.zimmerman said: Robert and Jeff,

Thank you for the thoughtful input. These are certainly problems to address as we consider how data flows between multiple entities, conclusions are documented, and source data is recorded. If the right data can be maintained during the sharing of records, perhaps constraints can be established to help aggregate and reduce duplicate data where the information is exactly the same. I believe the future will lead to a much greater abundance of data and we will need to address how to deal with the overload.

LegacyUser

Jeff Wiseman said: Robert, you're making me blush
:-)
So would the reason for you to be disappointed with me come from a) Me not providing a content in my message that was really relevant to your message, or b) me just not responding at all (i.e., me not behaving in a predictable fashion)?
:-)

LegacyUser

Robert Wren said: Ahhh, blushing fits you, Jeff.☺☺☺