17 replies to this topic

[ketchell]

Could someone confirm if these assumptions are correct if importing TMG with direct option via RM? Just making sure my list of what I have to fix after final transfer is accurate.

 

I have 3 custom census tags. 2 of 3 are imported as shared facts. Of the 2 that import as shared facts the sharees and roles (aka TMG witnesses/roles) are imported; however, the sentence template for that role is not imported. All sentences would have to be developed from scratch. Is this correct? That RM deletes all the "witness" sentence template as it doesn't translate into RM?

 

One of the census tags is imported into RM but only as an individual. I have set it up the same way as the other 2, so not sure what to ask. No family share is made by RM. This is a tag for the 1790-1840 censuses when the sharees are not explicitly named, only the head of household. However, in the other two census tags/facts, I have only a principal, and then the roles, not a second (eg., spouse) listed, so they seem the same. Still working on what could be different but if someone has experienced this would appreciate ideas as to why 2 not all 3 don't import as shared fact.

 

Overall while RM does a good job in translating data from TMG, it looks like most of the sentence templates for each facts will have to be redone as I used M1-6, etc. and those are imported as is. That's OK, just need to know. So my question is -- I change the fact type sentence template, go to the person toedit the principal and sharee. For the principal the revised template is not applied. I have to go into customize sentence and click the reset to default button. Is this normal? RM does not apply the revised sentence template to all the existing ones? These were not individually customized sentences in TMG, they were the global tag sentences.

 

On this same line, I setup a sentence template for a shared fact for the role sharee. But it did not get applied to all the people already imported in as that role, and there is no "reset to default" button. 

 

In any case, having to go into each principal and/or sharee to change the default sentence would be quite time consuming. Is there not a "change this globally as the new default sentence" in RM?

 

Forgive my naive questions. I'm new to importing TMG into RM and want to do an efficient but thorough job including simplifying out of my complex sentences but do want to retain shared facts. I'm probably just missing something obvious.

 

Debra

 

 

 

 

 

 

[ketchell]

I just went back to look at the RM default Census and Census (family) fact types. They look exactly the same. So which fact do you alter the sentences in if you are using the shared census fact? Maybe that is the mixup with some of my long description below. Should I be revising the sentence templates for principals and roles only in the family fact type and leave the non-family duplicate alone?

[TomH]

I'm not a TMG emigre so I am not well versed in the ins and outs although I did have a hand in some of the early issues. Jim Byram would be your best bet - you can find him on this board and PM him to get his attention.

 

On the Edit Person screen, the built-in "Census" and "Census (fam)" types will be so displayed. However, check to see if you have more than one of these fact types in the Lists > Fact Type List; if so, then you have a custom fact with duplicate labels (its the Abbreviation that shows in the Edit Person screen). Change its Name/Abbrev to something unique so you can tell which one is used. It is the roles for that fact type that control what the default sentence is for each sharer.

 

If you are finding that you have to go into the Edit Person > Fact > Customize sentence > Reset to default to get the local sentence to change to the default, then it is a custom local sentence and the only facility within RM is to do that one by one. 

 

You could use SQLite to batch change facts from one type to another and to remove all custom local sentences.

[Jerry Bryan]

Like Tom, I'm not a TMG emigre, but I think your situation could be clarified a bit with an understanding of terminology on the RM side of the house.

 

Of the two census facts in RM, one is what RM calls an "individual fact" and one is what RM calls a "family fact". RM's individual facts are like birth and death and apply only to one person. RM's "family facts" are like marriage and divorce and apply two individuals who are usually described as spouses even if they do not have a marriage record. RM's "family facts" might better be called "couple facts" or "spouse facts" because they do not apply to the children. Indeed, new RM users are often perplexed to discover that RM's Census (family) fact does not apply to the children who are enumerated in the census entry. And in fact it is sometimes stated on these boards that RM's developers didn't really intend that anybody use RM's Census (family) fact and that it was included in RM only for compatibility with the GEDCOM standard.

 

Be that as it may, either type of RM census fact can be shared with other family members and having been so shared will show up in narrative reports for the sharee. There is a default and global sentence template for each fact type in RM, like for each tag in TMG.. You may customize any or all of these sentence templates. For example, if you have 10,000 individuals in your database with a birth fact and if you customize the default/global sentence for the birth fact, then the sentence for all 10,000 individuals will be changed all in one fell swoop without having to customize the sentence template 10,000 times.

 

When a fact is shared in RM, the fact must be shared as a roll and there becomes a default and global sentence template for the roll. The default and global sentence template for the roll is separate from the default and global sentence template for the fact with which the roll is associated. And like the default and global sentence template for the fact itself, the default and global sentence for the roll may be customized and such customization becomes the default sentence template for all instances of that roll in shared facts. You don't have to customize each instance of shared facts.

 

Having said all that, the sentence template for any specific occurrence of any particular fact, shared or unshared, can be individually and locally customized. Such customization affects only one occurrence of the fact, shared or unshared.

 

What I don't know and couldn't figure out without a lot of additional research is whether RM's direct import from TMG is creating default and global sentence templates on the RM side of the house or whether RM's direct import from TMG is creating individual and local sentence templates on the RM side of the house. For all I know, it may depend in part on what RM finds in TMG. But if RM's direct import from TMG is creating individual and local sentence template on the RM side of the house and if you wish to change these templates, then your only options are changing the templates one at a time in the RM user interface or changing them globally with SQLite. I would prefer to guess that the templates are default and global in RM instead of customized and local, but I really don't know which is the case.

 

Jerry

[ketchell]

Thank you both for such detailed explanations. It is difficult to understand the why of some of the import translation. I will do more experimenting with some changes on the TMG side and reimport, and then try SQLite option to see what might clean up the data. I can see why many RM users don't share facts. Since TMG was based on individuals and any tag could be shared it is quite an adjustment with a large database developed in TMG over many years. I like RM but it is different. I've delayed moving to RM becasue of Second Site, but with GedSite, it is now time to move over to RM.

[Jerry Bryan]

Since TMG was based on individuals and any tag could be shared ......

 

I do own a TMG license even though I have never used it very much. So I know just enough about it to be a little dangerous. It is my observation (which may not be entirely correct) that one of the most jarring aspects of RM for TMG emigres is RM's distinction between individual facts and family facts. Indeed, RM doesn't actually need roles and witnesses and the sharing of facts to record information about spouses and their marriages. RM supported spouses and marriages long before it supported roles and witnesses and the sharing of facts.

 

It's like the distinction in GEDCOM between INDI records and FAM records (or FAMS and FAMC records). But in that respect, RM is using the same data model to represent spouses and marriages as nearly every other piece of genealogy software in the world, with the exception of TMG and SecondSite. I'm not saying that RM's data model for spouses and marriages is better than TMG's. Indeed, it probably isn't. Rather, I'm saying that RM's data model for spouses and marriages is pretty much the standard model.

 

Jerry

[Jim Byram]

There are some fundamentals to understand.

 

RM does not import TMG principal sentences for tag types that it imports as standard RM fact types. This includes Census. It uses the default RM sentences. Some differing roles and their sentences should be imported.

 

Although TMG principal roles will be imported, RM has only _one_ principal role with one principal sentence.

 

Any fact type can have witnesses (aka... can be shared) and you can have multiple witness roles.

 

The difference between somefact and somefact(family) is that the first has one principal and the last can have two principals.

 

You need to review every fact type (including the RM standard fact types) and make sentence edits as needed. You are going to need to edit the sentences for witness roles for standard fact types and all sentences for custom fact types.

 

You need to decide what sentence you want for the principal of each fact type and eliminate those extra principal roles that were imported from TMG.

 

Some (actually most) RM standard fact types do not have the description field enabled. You will want to enable the description field for some of the fact types since the description field can be used in sentence templates. There is no sentence variable for the RM fact note field. The note fields can be appended in RM narrative reports but that is sloppy to me coming from TMG so I use the Description field and do not output note fields.

 

You need to go through everything in every master list in the RM database and clean things up. It'll take a while. 

 

It took me two month of intense effort to make the conversion but I planned carefully and made dozens of punch lists and supporting list files from TMG to work through. And I occasionally find things to fix that were missed.

[ketchell]

Jim,

 

Thank you Jim, your TMG->RM experience is invaluable. Last year you saved my corrupted TMG database. This year you lead me in the right direction to find the culprit roles that were causing the (fam) fact types when importing into RM. You were right -- it takes a lot of time but ultimately I now have clean tags in TMG to import into RM. Thanks for the practical advice.I am using this move as the opportunity as a major cleanup, some carried over from UFT to TMG move many years back; and a cleaner database will help in remaking all those witness/role sentences in an efficient way in RM. Good to know that I should plan to touch everyone. As you say, intense effort but the cleanup will ultimately make the GedSite output better. This time avoiding local witness/role sentences as those won't import into GedSite

 

I had discovered the description field not checked, and had made those changes in most. Now have that across the board.

 

I went back to the TMG Utility and its role usage report and the renaming the P2 role. That solved most of the issues. I discovered the final culprits were the P1's I had renamed to "notfound" for some census in the past. Once those were all cleaned up the import into RM only has (fam) fact types from a couple. 

 

If you have any thoughts on the next two items of cleanup, that would be much appreciated.

 

1. Role naming for sentences. Previously I had used in the census/residence-like witnesses the dau/son/etc. I've read much about the sentence construction being facilitated by instead using the parent, grandparent, AuntUncle vs dau/son/child, grfanddau/son/child, niece/nephew. What approach have you found works best for sentences in RM to GedSite? 

 

2. Value of having CEN1790 etc. for all census years vs general Census when using RM to GedSite? I had used Census1,Census2,Census3 to account for different roles/sentences for 1790-1840, 1850-1870, 1880+ (no names, household but no role, 1880+ role explicit). It appears from Tom's SQL site that I could use those tools to create separate census years out of the fact plus year. Have you determined a good use for this as that would require sentences for each of those census year facts?

 

Knowing how experts transfer and what they change as they move their data and go into cleanup is very helpful for those of us starting the process, especially if planning on GedSite for output.

 

Debra

[Jerry Bryan]

I used Tom's SQL procedure to convert all my standard Census facts to year by year Census facts. There are overwhelming advantages to doing so while using RM. But curiously, when I export GEDCOM from RM for import into GedSite, I discover that the GEDCOM contains only the standard Census facts and not the year by year Census facts. In other words, the GEDCOM contains

1 CENS
2 DATE 1930

etc., just as if I had never converted over to using year by year census facts.

 

At the same time, I have been switching my City Directory facts over to year by year City Directory facts. There were few enough of them in my database that I chose to convert them by hand rather than adapting Tom's Census procedure to the City Directory. But when I export GEDCOM from RM for import into GedSite, I discover that the GEDCOM still contains the year by year City Directory facts, viz.

1 EVEN
2 TYPE 1947 City Directory
2 DATE 1947

The only thing I can think of that's different is that the Census fact is a built-in fact in RM for which there is a standard tag in GEDCOM, whereas City Directory is a user defined fact in RM for which there is not a standard tag in GEDCOM. Nevertheless, I don't understand why my GEDCOM for Census doesn't look exactly like my GEDCOM for City Directory.

 

Jerry

[TomH]

Jerry, my SQLite script at Fact Type - Convert Census to yyyy Census and back kept the same value "CENS" in the field GedcomTag in the FactTypeTable for the 'yyyy  Census' custom fact types. That could be said to be an oversight if they should have been changed to "EVEN". You could readily change them and see if that exports better to GEDsite. Let me know and I will revise the script. I think the same thing might happen with drag'n'drop.

[Jerry Bryan]

I will do the experiment as you described, but I want to think about whether a change in your script would be warranted or not. By the time my GEDCOM gets to GedSite (or to anywhere else, actually) it's probably an advantage that the "per year" census fact types in RM are converted to the conventional CENS tag in GEDCOM. Indeed, the current behavior is much easier to manage on the GedSite side of the house than if the RM fact types came across in GEDCOM as separate GEDCOM tags because I only have to manage one tag type in GedSite. Indeed, before I submit my GEDCOM to GedSite I run a Notepad++ macro that converts the "per year" City Directory tags in the GEDCOM all to being the same City Directory tag. It's really only in the RM user interface where there is a advantage of having separate fact types for each census or city directory year.

 

I confess I never looked under the covers of your script to see what it was doing with the GEDCOM Tag in the FactTypeTable. So that explains the behavior I'm seeing in my GEDCOM export. I thought it must be something strange that RM itself was doing. So it's good to know how it's really working.

 

Jerry

[KFN]

From my perspective the two CENS tags in GEDCOM 1) FAM.CENS 2) INDI.CENS  are not equivalent even though the code looks the same. 

 

1) FAM.CENS is a family level census tag meaning everyone in the family is noted in the census.  In many cases some of the individuals in the family are not in the census, a) not yet born children  b ) children away from home c) dead parents

2) INDI.CENS is a individual or person specific census tag.  This would be for the specific person noted in the census register.   

 

Personally I think the INDI.CENS tag is most appropriate for ALL recordings of the census.  It is by far the harder to add to any system because you will probably have to add the Census tag and the Citation several times (one for each member in the actual census) but it is also the most accurate to the facts.

 

I would also not make any distinction between what kind of Census this fact or tag entry is.   This is a mater for the citation and source document to report to the reader.  A Census at the city is the same as a state or national census with regard to the fact being added to the individual (or family), the citation/Source will denote the type of census when you review the SOURce_record tags SOUR.DATA.AGNC (i.e. the Agency tag)

 

Simply my opinion.  Take it for what it is worth!!

[Jerry Bryan]

So I created a fact type of 1950 Census manually. As expected, the GEDCOM tag type is  EVEN. There is no way that I know of in the RM user interface to see the GEDCOM tag type for a fact type, but it's easy enough to see in the RM database with SQLite or to see it in the GEDCOM itself. The salient GEDCOM itself is as follows.

1 EVEN
2 TYPE 1950 Census
2 DATE 1950

This works just fine with (for example) Gedsite, and I'm sure with most any other genealogy software. However, I still think I would suggest not changing the script and leaving the GEDCOM tag type as CENS.

 

Jerry

[Jerry Bryan]

1) FAM.CENS is a family level census tag meaning everyone in the family is noted in the census. 

Actually, not everyone in the family is noted in the family level census, which is a frequent criticism of the family level census. The family census only prints out with the spouses and not with the children. For that reason and several others, I certainly agree that the individual census is the one that should be used most of the time. Well, the alternative might be to use the family census and then to share the family census with each of the children. But I still think that the individual census entries are the best way to go most of the time.

 

The situation with the family situation is common to many other "family" things in RM: most such "family" things only go with the parents and not with the children.

 

Jerry

[ketchell]

To redirect this back to one of my two questions moving from TMG to RM

 

2. Value of having CEN1790 etc. for all census years vs general Census when using RM to GedSite? 

 

Jerry I know you have CENXXXX and are using GedSite.Gedsite can product a 3 column output for census that shows CENSLABEL, Date=Year, Sentence. So the year split isn't needed for creating HTML by year if using GedSite.Because I don't find the RM individual display that useful compared toTMG which included all individual facts (shared or not) upfront including birth of a child. Timeline is OK, but I find using Gedsite output much more useful in reviewing my data and just making corrections in RM. So I'm wondering what the practical value is in having CENSXXXX facts if not creating output in RM? Any thoughts?

 

I will try Tom's swapping YEAR for CENSUS and back to experiment but wondering the value added. Thanks!

 

Debra

[Jerry Bryan]

I will try Tom's swapping YEAR for CENSUS and back to experiment but wondering the value added. Thanks!

 

There are two reasons inside of RM for using year census facts rather than just census facts. Neither reason has anything to do with reporting inside of RM and neither reason has anything to do with GedSite. I doubt that very many RM users go with the year census facts, and any individual user would have to evaluate the reasons to do so to see if those reasons are sufficient to induce them to switch the way they handle census.

 

The first reason has to do with RM's searching and marking. For example, suppose you just wanted to search for all individuals who were enumerated in the census in 1850 in Texas. So you would set up a search for census date equals 1850 AND census place contains texas. The problem is that such a search finds individuals who were enumerated in 1850 in Tennessee (census date equals 1850) and who were enumerated in 1860 in Texas (census place contains texas). There is no way to force both search conditions to test the same fact. Rather, both search conditions test the same person.. And of course the same problem would happen if  you were marking to color code or to create a group.

 

The second reason has to do with RM's People View which is an amazingly useful and powerful facility. You can filter the group of people to be displayed in People View by a group, and you can include any individual fact date or individual fact place as a column in People View. You can sort the display by any column with a single click at the top of the column. The problem with using the standard census fact and People View is that the view shows only one row per person. So suppose that somebody was enumerated in the 1850 census, the 1860 census, the 1870 census, and the 1880 census and suppose that you use the standard census fact. Under these circumstances, People View can only show one of the census facts in the census column and you have no control over which census fact is chosen. If instead you have year census facts, then the 1850 census place can be one column, the 1860 census place can be a different column, the 1870 census place can be a different column, etc. It's an extremely powerful way to look at your data. This problem with People View is not specific to the census fact. Rather, the problem exists for any fact which occurs multiple times. For example, some RM users will enter multiple birth facts if they have conflicting data about the correct birth date or the correct birth place. I try to avoid that problem by entering only one birth date and including any conflicting data in the birth note. But I do have the same problem with city directory data as I do with census data, so I split city directory into year city directory facts just like I split census into year census facts.

 

Actually, this issue might have something to do with GedSite depending on how you are using GedSite. GedSite doesn't need the year census facts or the year city directory facts. Indeed, if you are using GedSite sentences in GedSite instead of RM sentences in GedSite, you might potentially have to define sentences in GedSite for every census year and for every city directory year. Except that Tom's procedure sets up things in the RM database so that year census facts are exported as if they were just plain census facts. That works perfectly for me. In the case of City Directory, the year City Directory facts are exported by default as  separate year City Directory facts. So to make things easier for myself on the GedSite side of the house, I use a very simple Notepad++ macro to convert the year City Directory facts to just plain City Directory facts inside of the GEDCOM before importing the GEDCOM to GedSite.

 

Jerry

[ketchell]

Thanks for the detailed use case scenario on the CENSXXXX Jerry. I will have to experiment and decide whether to change back to that format vs plain Census tag. The People View would be very useful. 

[Jerry Bryan]

Thanks for the detailed use case scenario on the CENSXXXX Jerry. I will have to experiment and decide whether to change back to that format vs plain Census tag. The People View would be very useful. 

If you decide to switch, and if you are only concerned with census and not with any other fact types such as city directory, then Tom's procedure makes it extremely easy on the RM side of the house to switch, and Tom's procedure also makes it very easy to switch back if you change your mind. Also, Tom's procedure causes the CENSXXXX facts to go into GEDCOM as plain CENS facts, so there is no impact at all on GedSite either way.

 

Jerry