Jump to content


Photo

Census (Family) and Residence (Family) fact type problems

census residence family

  • Please log in to reply
18 replies to this topic

#1 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 127 posts

Posted 03 July 2017 - 08:57 AM

Can anyone tell me how to convert fact types Census (Family) and Residence (Family) to Census and Residence?

 

When I first started using Roots I used the family fact types thinking it would save me data entry time. I later learned that the use of the family versions was not recommended because of data transfer issues with other programs. I then started using the basic census and residence types, but I still have some old ones in my tree.

 

Now I have started using the new Ancestry TreeShare and have run into the problem (discussed recently in this forum) with the conversion of census records to residence with Ancestry. The suggestion to change the Roots fact type temporarily to Residence, then back again to Census after the sync is completed, does not work for the family fact types. I get that, so I need to convert my older census  and residence family types to get TreeShare to work properly.

 

So far I have found the only way to do it is to create a new census or residence fact and copy the information from the family fact type to it, then delete the family one. This is a pain, especially if the family type fact is also shared.

 

Wish I had known this from the start .................  :(

 

Any suggestions would be greatly appreciated.

 

Thanks

Rick


RickL


#2 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2704 posts

Posted 03 July 2017 - 09:02 AM

So far I have found the only way to do it is to create a new census or residence fact and copy the information from the family fact type to it, then delete the family one. This is a pain, especially if the family type fact is also shared.

 

That's the only solution because that's the way family facts work. I recommend strongly against using family facts except for the bare minimum where you have to, such as marriage and divorce and any fact types related to marriage and divorce.

 

Jerry



#3 genealogy4primm@earthlink.

genealogy4primm@earthlink.

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts

Posted 03 July 2017 - 10:12 AM

Unfortunately, a Family Fact Type can not be interchanged with an Individual Fact Type in RM's Change Fact Type. However that might be a possibility using a third party software utility like SQLite. Tom Holden's "SQLite Tools for RootsMagic" website would be a place to check out.



#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5560 posts

Posted 03 July 2017 - 11:59 AM

The SQLite scripts on the following page and my RMtrix utility does what you want. http://sqlitetoolsfo...d to Individual

This capability should be integrated in RootsMagic to let users out of the trap that RM Inc has set for them.

Tom user of RM7230 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a growing bundle of RootsMagic utilities.


#5 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 127 posts

Posted 05 July 2017 - 09:27 AM

OK I understand that there is no RM tool for converting family events to individual. This means, I guess, that there are only two options (well three if I just leave things as they are).

 

First is to manually convert all the family events to individual. Works fine but very labor intensive.

 

Second, is to try the tools in RMtrix.

 

I've loaded the program, and have successfully run it for shared events to split them into individual in a copy of my database. However, still I have a couple of questions.

 

1) When I try to copy the changed individual's record, from the copy data base back to mine, the events merge and I end up with shared facts and individual facts duplicated. Is this because the purpose of running the tool in a copy of my data base is so I can export the changed data to a GEDCOM or to Ancestry without shared events? And not to replace my data base? [I'm reluctant to run it in my database until i'm sure what it does] Confused.....a little.....

 

2) I'm not seeing how this deals with the issue of Family Events (which are apparently different from just shared events). I can't see that the RMtrix tool does anything for those. [I could be just missing something, just started using RMtrix yesterday.]

 

Any hints/ clarification would be appreciated

 

Thanks 

Rick

 

BTW - this forum is awesome - great place for a "newbie' to get help


RickL


#6 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2704 posts

Posted 05 July 2017 - 10:53 AM

I'll let Tom speak to RMtrix, but let me try to address shared events vs. family events. The basic data model used by an early genealogy program called PAF involved individuals and families. This same basic "individuals and families" data model is used in GEDCOM, which is the standard file format for exchanging genealogical data between genealogical software. The use of the "individuals and families" data model by PAF and especially by GEDCOM has had the effect of promulgating the same data model to much other genealogy software. Not every genealogy software uses this data model, but even those that do not use it for their own internal operations have to deal with the model if they import or export GEDCOM files as a way of exchanging data with other genealogy software.
 
So what does this "individuals and families" data model mean? Suppose you export a GEDCOM from RM and as a part of that export you export John Doe, his wife Jane Smith, and their children Samuel and Sarah Doe. Suppose that you are exporting a large database and that John Doe is the 79-th person exported, Jane Smith is the 80-th person exported, Samuel Doe is the 81-st person exported, and Sarah Doe is the 82-nd person exported. The way GEDCOM is structured, that means that there will be an INDI record (an individual record) for John Doe as individual #79 and similarly an INDI record for the other three family members as individuals #80, #81, and #82. Data such as a person's name, birth date, death date, etc. is linked to these INDI records. So for example, the GEDCOM will not say that John Doe was born on 12 Aug 1848, rather it will say that individual #79 was born on 12 Aug 1848 and that the name of individual #79 is John Doe.
 
I would emphasize that these individual numbers and family numbers don't mean anything except that they are unique within the GEDCOM. They often are not carried forward into a piece of software that is importing the GEDCOM.
 
Nothing in the INDI records says that John Doe and Jane Smith were husband and wife, nor that John Doe and Sarah Doe were their children. That's where the "families" part of the "individuals and families" data model comes into play. Suppose that this Doe family were the 18-th family exported in the GEDCOM. Then there will be FAM records (family records) for family #18 in the GEDCOM that tie the family together. There will be FAMS (family spouse) records for family #18 which are for individuals #79 and #80 that say that individuals #79 and #80 were spouses in family #18. There will be FAMC (family child) records for family #18 which are for individuals #81 and #82 that say that individuals #81 and #82 were children in family #18. And there will be a FAM record for family #18 for the family as a whole.
 
Except for perhaps sounding a little techie, this data model perhaps may seem pretty simple and pretty obvious and straightfoward. But there are some interesting implications of the model, both good and bad. For example, birth facts are connected to INDI records and marriage facts are connected to FAM records. So if you look for a marriage record for individual #79 and #80 (John Doe and Jane Smith), you will look in vain. Instead, you have to look for a marriage record for family #18 and you have to observe that individuals #79 and #80 are the spouses in family #18. On the other hand, it means that the marriage record is only in the GEDCOM file once, and it's in the GEDCOM for family #18. It's not in the GEDCOM twice, once for individual #79 and again for individual #80.
 
Another little curiousity is that Samuel Doe and Sarah Doe are children in family #18, but the marriage fact has nothing to do with them. The marriage fact is really a spouse fact associated with FAMS and is not really a family fact associated with FAMC or FAM. That seems pretty unremarkable for a marriage fact, but it can become really confusing because family census facts really work the same way. They really only work for the spouses and not for the children.
 
This brings us back to RM. The RM database uses the "individuals and families" data model and it has both individual facts and family facts. Individual facts are such things as birth, death, and burial. Marriages and divorces and the like are not individual facts in this model even though there are two individuals who are parties to the marriage or divorce. Family facts are really spouse facts and they include such things as marrriage, divorce, marriage bond, marriage bann, and the like.
 
All RM individual facts have one individual who is the principal to the fact. All RM family facts have one family which is the "principle family" for the fact. The family fact is really only for the spouses and not for the children. Being a child in RM is not a fact. Rather, it's implicit in being a FAMC (a family child) for the family. And truly, even being a spouse in RM is not a fact. Rather, it's implicit in being a FAMS (a family spouse) for the family. So marriage is a fact (a family fact) but being a spouse of another person is not a fact. Birth is a fact (an individual fact) but being a child of another person or persons is not a fact.
 
By contrast, something like TMG does not have family facts. Rather, it has individual facts that can have two principles to the fact instead of one. I'm not sure how to characterize the ancestry.com data model. It certainly doesn't have family facts in the same sense as RM. But I'm not sure it has individual facts with two principles to the fact like TMG. Without being really sure, it looks like the ancestry.com data model is treating marriage as two separate events, one for each of the spouses. But having said that, it obviously must be linking the two separate event together somehow or other.
 
Finally, we get to shared facts. There is nothing in the old PAF and GEDCOM "individuals and families" data model that accomodates shared facts. So each vendor sort of has to create their own version of the data model for their shared facts. What happens is that there is a principle to a fact - the principle being the person being born, the person being buried, etc., and there can be additional people who have some sort of role in the event. A role for a birth might be a midwife. A role for a burial might be a pallbearer. Generally speaking, the roles can be anything you wish.
 
So for example, Samuel Doe in our mythical family might have been born in 1872 and the midwife who delivered him might have been Rebecca Williams. So you might share Samuel's birth fact with Rebecca Williams with the role of midwife. Then if you ran a report for Rebecca Williams, it might say something to the effect that Rebecca Williams was the midwife who delivered Samuel Doe in 1872. So even though the event was "Samuel Doe was born in 1872" and you shared the fact with Rebecca Williams, a report obviously would not say that Rebecca Williams was born in 1872. Duh! Rather, a report would say that Rebecca delivered Samuel and that her role was midwife.
 
RM's implementation of shared facts maintains the limitation that each fact has only one principle to the fact, unlike TMG's model with more than one principle. But RM's implementation of shared facts is extremely flexible about how many people can share a fact and what role each person has. But just remember that a marriage is not a shared fact. It is a family fact in RM. Well, a marriage can be shared. But if so, it would be shared in the sense of somebody having the flower girl role and somebody having the minister role and somebody having the bridesmaid role. Etc.
 
Jerry


#7 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 127 posts

Posted 05 July 2017 - 11:27 AM

Thanks Jerry,

I have to admit, that's the best explanation of the GEDCOM, shared events, etc. that I have ever read.

 

I think maybe I have been "over thinking" this.

 

I created a new data base and copied my old data base into it. Then I ran the RMtrix for share split against the entire new database instead of trying to correct by individuals. The result was, as far as I can tell so far, that all my shared records have been fixed. However, the family events (such as census and residence) stayed the same and will have to be manually fixed I suppose.

 

Thanks you very much

 

Rick


RickL


#8 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5560 posts

Posted 05 July 2017 - 05:47 PM

I agree that Jerry's training, experience and aptitude as an educator produce many highly readable and comprehensible posts. They should be collected into a compendium.

As to RMtrix, there is a second tool, Unshare facts, which you can run after splitting to rid the database of the witnesses or sharers, leaving it with just individual events.

I've forgotten what it does with Family facts but you indicated they are left that way for the principals. That makes sense because they are standard GEDCOM. But, I think you want to split them (or some of them). Which ones and why?

Tom user of RM7230 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a growing bundle of RootsMagic utilities.


#9 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 127 posts

Posted 06 July 2017 - 01:59 PM

Tom,

I have done as you suggested and it did clear the witnesses. Basically, it changed everything to do with "share" and converted them to "individual".

 

But, as far as I can tell, it did not do anything to the Census (family) or the Residence (family) events [unless the event was also shared beyond the spouse].

 

As a result, I am manually splitting those family events, and not creating any new ones, or sharing any events either for that matter.

 

I'd recommend that something be placed in the help files so new users will not go down this path.

 

Thanks for the help.

Rick


RickL


#10 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5560 posts

Posted 07 July 2017 - 06:46 AM

I'll look into a conversion of Census and Residence 'family' events into 'individual' ones via SQLite. Won't be today...

Tom user of RM7230 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a growing bundle of RootsMagic utilities.


#11 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 127 posts

Posted 09 July 2017 - 09:35 AM

Thanks Tom, that would be great, no rush  :)

 

BTW, I have continued working with the new Ancestry share tools over the last week and I have noticed the following:

 

After running the share "split" and "unshare facts" tools, my Roots data base still shows the "census (fam)" and "residence (fam)" fact types, but all the shared relationships in these have been eliminated or changed to individual records. i.e. the shared person of a census (fam) now shows census (fam) but there is no longer a shared relationship to the principle person. That is what I wanted to do but its just sort of being called the wrong thing I guess. 

 

Also, when I copied by Roots database to a new tree in Ancestry, these facts show up there as "Census (fam)" and "Residence (fam)" with no shared relationship between the Principle and the witness. Also, the Fact Type Edit for these fact types has "include for GEDCOM"  checked. I assume that is why they did copy over the Ancestry OK.

 

I don't know if all this makes sense to you or not, but I'm continuing on and not using Census (fam) or Residence (fam) fact types in future.

 

Thanks again

Rick


RickL


#12 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts

Posted 09 July 2017 - 10:11 AM

Census and Residence facts for a family never made sense to me. I do not use them.

#13 mjashby

mjashby

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts

Posted 09 July 2017 - 10:15 AM

Rick,

 

I believe what you have experienced is down to the explanation given elsewhere that Ancestry Tree doesn't understand/use the concept of family events at all. in Ancestry Tree every event/fact is stored as the Individual Level, even Marriages.  The only way I've found of accurately drawing in 'true' Family events such as Marriage/Marriage Banns correctly is to enter an appropriate 'Marker Fact', linking the couple, in RootsMagic. You can then use the Update Feature in TreeShare instead of New Event and the detail gets transferred/recorded correctly.  This is another possible reason why 'mass' data synchronisation could prove problematic.

 

As KFN, I have never seen any practical reason for using a Census/Residence Family Events as Family Events in GEDCOM are only applicable to couples and not the 'whole family unit'

 

Mervyn


MJA

"A Mac User with Windows Tendencies"


#14 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5560 posts

Posted 09 July 2017 - 03:08 PM

mjashby is right. The Census (fam) and Residence (fam) events that you see with no spouse in RM are due to a shortcoming or bug in the interface between RM and Ancestry. These RM (fam) fact types remain coupled when uploaded to Ancestry (i.e., you see the spouse with the fact in the Ancestry Member Tree) but when downloaded to RM, they become uncoupled. RM relates to them as a (fam) fact type but operates on them as an Individual fact type. Its event record points to the Residence (fam) fact type definition but characterises it as an (indiv) fact type so it is tied to the Person, not the Couple (family). That's why the name Residence (fam) appears (from the definition) and the default sentence has [couple] which can't retrieve the names because the event points to the Person, not the Family (couple). You could safely change the Fact Type in RM from (fam) to (indiv) one by one in Edit Person > Tools or en masse using SQLite:

UPDATE EventTable
SET EventType = 18 -- Census
WHERE EventType = 311 -- Census (fam)
AND OwnerType = 0 -- Person
;
UPDATE EventTable
SET EventType = 29 -- Residence
WHERE EventType = 310 -- Residence (fam) 
AND OwnerType = 0 -- Person
;

However, you then have the challenge of propagating those changes back to Ancestry. I would say that RM will come up with a fix to properly handle what Ancestry somehow knows are coupled events and must surely transmit sufficient information through its API for RM to understand that. If not, then FTM2017 must have to confront the same issue and it would be unworkable for everybody. 


Tom user of RM7230 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a growing bundle of RootsMagic utilities.


#15 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 127 posts

Posted 10 July 2017 - 03:59 PM

Wow!! What a mess.

 

I think the best thing for me to do is manually change these family fact types to individual in RM and do an update thru the tree share to fix Ancestry. ( I have virtually no experience in SQlite and I would probably make a bigger problem trying to do it - does sound like something I want to learn though). 

 

Thankfully, I stopped using the family census and residence fact types, on advice from this forum, quite a while ago, and I have a limited number of them to fix.

 

Thanks to everybody for the suggestions,

Rick


RickL


#16 pbooth99

pbooth99

    Member

  • Members
  • PipPip
  • 14 posts

Posted 12 October 2017 - 11:11 AM

Related question - do people find value in using census facts? I began with ancestry.com, which only saves a small fraction of the information present in a census return ignoring, for example, occupation.

#17 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7311 posts

Posted 12 October 2017 - 12:21 PM

I transcribe the census information into the Source's Research Notes. Which is attached to the census or residence fact. I would use the occupation fact for anything noted on the census regarding that and then attached the source that applies to it there. If my ancestor was a farmer there might be 5 census's as the source of that information. 


Renee
RootsMagic

#18 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2704 posts

Posted 12 October 2017 - 01:06 PM

I find huge value in census facts. The census data tells a story in its own right, over and above the value of census data as a source. Hence I treat census data both as a fact and as a source.

 

I transcribe and annotate census data onto my own web site, which is separate from RM and which is not created by RM. I then copy and paste my census transcriptions into census facts in RM. Finally, I copy and paste my census transcriptions and my census annotations into Source Research Notes in RM. I download census images and store them on my Web site and link them into RM.

 

Jerry



#19 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts

Posted 15 October 2017 - 05:26 PM

As a researcher I use census as a starting point for much of the family units. My most important find was searching in an apartment building where my grandfather was living and in another apartment I found a woman that with some additional research turned out to be his aunt.