Created at Ancestry using their Default fact Cause of Death
syncing down to RM come as Fact CauseofDeath.
I have previously created a Fact on RM Cause of Death (exactly as Ancestry)
It ups to Ancestry named correctly but is not recognized as a default fact of Ancestry.
You can’t tell that until you go to the source and try to add a existing fact to it and you will not see that RM created fact just description. (its description field only).
Doesn’t appear correct in either direction
Shouldn’t RM TreeShare have the same facts as Ancestry?
Should have, maybe! Do they? No! Ancestry and RM have different data models and they do not necessarily line up with each other. Just naming the facts the same is not adequate to make that happen. Once you sync down from Ancestry and have gotten the ‘CauseofDeath’ fact, have to tried changing it to the ‘Cause of Death’ fact that you have created? I suggest making sure the file is backed up before you do it.
I think something else is going on.
There are confounding problems re Cause of Death in GEDCOM exchange between Ancestry and RM. And between RM and others due to differences in database design. CoD is defined in GEDCOM as an attribute of the Death event with the subtag CAUS. RM does not support it and user workaround (if not even the advice of RM Support) is to enter the CoD in the Death event Description field which is a violation of the specification which only allows “Y” on the same line as the DEATh tag. Something similar is likely going on in TreeShare.
This is not a Gedcom exchange.
This is the programing of the Ancestry to RM API that is incorrect.
Ancestry API is fixed (most of the time) RM needs to match their end correctly.
Cause of Death has been at Ancestry, as far as I remember, forever.
Ancestry dictates what the API does or does not share. I really doubt that RM8 is going to completely alter their entire database structure to accommodate the extra bits that Ancestry shares. Do so is very likely going to cause far more problems that some brief inconvenience that you are suffering. Simply put, if RM8 is not meeting your needs, then find a program that does? You have precisely one other choice.
I suspect the API closely parallels Ancestry’s interpretation and application of GEDCOM and both are defined or constrained by Ancestry’s database design. So, too, RM’s translation of GEDCOM and Ancestry’s API is limited by RM’s database design which currently cannot support the Cause of Death attribute or, afaik, any of the ATTRibutes defined in GEDCOM. So it is likely that RM would have to revise its database design and program to provide support for Cause of Death or other ATTRibutes. As kfunk has indicated, it would require program revision across wide swathes of inputs, user interfaces and outputs, not a trivial undertaking and not one done yet despite decades of incompatibility starting with Family Origins.
That TreeShare introduced bidirectional data transfer with an Ancestry Member Tree has brought more light to bear on this incompatibility. Your complaint is one example. Maybe RM will do something about it but don’t hold your breath.
That a wonderful reply.
Especially that RM highlights their TreeShare with Ancestry.
As with most programs their are errors , not all, most most get fixed.
Its not a complete database re structure. its a minor bit of code.
It is a misinterpretation of one segment of the API from Ancestry.
Its got nothing to do with a gedcom. It is only Ancestry’s API.
They offer it up and its up to the programmer to use the offered data.
An export from Ancestry to a gedcom file uses the Ancestry data through a completely different internal program at Ancestry to export the data.
Actually it may well be a complete restructure. @TomH outlined why that may be. I also truly love when someone, who I know full well has never seen the RM codebase, decides what is a minor bit of code and what isn’t. So once again, if RM isn’t doing it for you, then it is upon you to explore alternatives, of which you have one.
I suspect that eventually changes will need to be done as programs move towards GEDCOM 7.X compliance, but whether that will fix your issue…well it is still probably several years away.
We seem to be arguing at cross-purposes from false assumptions because @frazid is reporting a problem that might be a failure of his own making and @kfunk and I accepted that he must be correct in stating that RM is at fault for not supporting the Ancestry Cause of Death fact type over TreeShare. Turns out after my wee test that we are all wrong. RM8 does import “Cause Of Death” from Ancestry and, in so doing, creates a custom Fact Type called “CauseOfDeath”. I then added in RM a fact of that type to a person and uploaded the change via TreeShare whereupon Ancestry correctly displayed the fact with the value I had entered into the RM “CauseOfDeath” event Description.
I did this test using RM 22.214.171.124.
TreeShare continues to list the person as Changed without flagging any differences in the comparison so that is misleading.
I also had a look at the GEDCOM downloaded from Ancestry and found that RM’s support of Cause Of Death via that transmission path lags that of TreeShare. Ancestry exports it as a custom tag “1 _DCAUSE” with a 2 NOTE value preceding the “1 DEAT” event. RM8 imports that into the Person (General) Note field without any name such as “Cause of Death”; no custom event is created.
Did some more trials:
- Confirmed that the CauseOfDeath event added on the RM side of TreeShare did get accepted by the AMT through TreeShare update as an Ancestry “Cause of Death” by disconnecting the database from Ancestry, TreeShare to a new AMT, inspect, and download its GEDCOM which showed the exact same “_DCAUSE” tag as the original download from the initial AMT.
- Learned that Ancestry does not completely preserve its own GEDCOM construct “_DCAUSE” as its “Cause of Death” Fact in a GEDCOM roundtrip from Ancestry and back; its value is placed in Other Sources > Unsourced Citation > View > Other Information rather than in the Fact’s only entry field “Description”.
- Learned that Ancestry does not recognise RM’s GEDCOM construct for its custom “CauseOfDeath” fact type created from the TreeShare download and then GEDCOM uploaded to a new AMT; it becomes a one-off per occurrence “CauseOfDeath” custom event with (empty) Date, Location, Note fields in addition to the correctly filled Description field.